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1.1  lenera.l  Description  Of  The  Problem 

Thin  thesis  describes  the  implemen ta tion  of  a methodcloay 

i. 

for  the  definition  of  alerters  using  relational  algebra 
expressions,  within  the  frameworx  of  the  relational  model  of 
data.  An  alerter  is  a program  which  monitors  a data  base  and 
takes  a predefined  action  when  it  detects  the  occurrence  of  any 
member  of  an  specified  sat  of  conditions.  The  specification  of 
this  set  may  require  the  use  of  non-triviai  means  of  expression, 

( 

as  it  may  involve  several  data  base  entities,  or  several  data 
operations,  or  both.  Therefore  the  high  flexibility  of  a 
relationally  complete  language,  in  a relational  data  base 
environment,  seems  to  be  ideal  for  the  implementation  of  these 


alerter  definitions 
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As  the  conditions  associated  to  the  alerters  are  expressed 
in  terns  of  the  information  contained  in  the  data  base,  it  can 
intuitively  be  saic  that  it  should  be  necessary  to  evaluate  the 
contents  of  the  data  case,  according  to  the  definitions  of  the 
alerters,  in  order  to  determine  if  one  of  the  conditions  has 
been  satisfied;  satisfaction  of  these  conditions  can  only  be 
achieved  by  updating  the  contents  of  tne  data  oase,  since,  as  we 
snail  see,  it  is  in  the  spirit  of  the  definition  of  alerters  to 
take  action  only  when  conditions  change.  On  the  other  hand 
certain  data  oase  updates  can  be  immediately  identified,  without 
reference  to  the  contents  of  the  data  base,  as  ones  tnat  can  not 
affect  the  existing  alerters;  therefore  as  it  is  the  case  that 
the  majority  of  data  base  updates,  by  their  nature,  should  be  of 
no  relevance  to  a set  of  alerters,  it  can  be  seen  that  an 
efficient  way  of  avoiding  the  evaluation  of  the  data  base 
contents  in  unnecessary  occasions  is  of  major  importance  in 
implementing  an  alerter  system. 

As  an  illustration  of  the  ideas  aoove , imagine  that  there 
exists  a data  base  containing  tnis  two  relations: 

EMPLOYEE:  ( £M P # , MA A E , 3 A LA  R f , DE PT # ) 

MANAGERS:  (EM  ?#,  DE  Pi’*  ) 


al  so 

imagine  tnat 

it  was  required 

to 

report 

the  name  and 

empi 

oyee 

number 

of  new  managers  as 

soon 

as  it 

was  reflected  in 

the 

data 

oase.  A 

relation  containing 

EM  P# 

, NAME , 

and  SALARY  for 

the  managers  could  ce  oDtained  as: 

project  EM P i , NAME,  CMP#  from 

join  Of  EMPLOYEE  ana  MAMAGERo  on  EEPT4 


t 
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It  can  be  seen  that  tne  mentioned  requirements  can  oe  satisfied 
if  this  relation  is  monitored  to  report  any  addition  that  is 
made  to  it. 


The  definition  of  the  alerter,  containing  the  operations 
and  relations  needed  to  express  the  relation  to  be  monitored  can 
oe  represented  internally  as  a data  structure,  which  we  will 
later  detail  and  could  hypothetically  be  defined  as,  say: 


define 


end ; 


alerter  AL1  = 
monitor  for  additions, 
indicated  oy  EM?#, 
tnen  report; 
target  » 

pro  j ec  t ( (El'.P#  , NAME,  CMP#  ) , 

■join  ( (DEPT#)  , (EMPLOYEE, MANAGERS)  ) ) ; 


Tne  previous  piece  of  meta-cooe  can  be  understood  as 
defining  an  alerter  wnich  will  monitor  and  report  any  audition 
maoe  to  the  relation  defined  as  •‘target-’,  using  CMP#  as  the  Key 
to  recognize  the  additions,  (tney  are  '‘indicated  by'  the 
appearance  of  new  CMPff's  in  tne  target). 


Tne  data  structure  generated  oy  an  equivalent  definition 
would  oe  used  to  maintain  and  evaluate  tiie  conditions  associated 
to  tne  alerters.  This  structure  snould  be  able  to  direct  tne 
evaluation  of  tne  uata  base,  and  aoie  to  help  in  the  decision  of 
whicn  oata  case  updates  are  relevant  to  the  existing  alerters. 


Tne  present  tnesis  is  Dased  on  a paper  Dy  Buneman  anc 
Clemons,  "Efficiently  Momtorina  Relational  Data  oases"  , wnere 
the  aforementioned  ideas  are  presented  (BUoE  7b],  ano  oeals  with 
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the  implementation  details,  algorithms  ana  aata  structures,  cf 
evaluation  of  alerters  in  a relational  environment.  Before 
discussing  tnis  implementation  in  more  uetaii,  we  now  oive  some 
informal  description  of  the  nature  and  use  ot  cienerai  alerters. 


1.2  Alerters 


tvnen  working  in  a data  base  env ironment , it  would  be 
desirable  to  ensure  tne  recognition  or  certain  states  of  tne 
information  wnenever  they  are  reached  uue  to  data  uase  updates. 
The  previous  point  oecomes  of  mucn  greater  importance  wnen  the 
work  is  taking  place  in  a snared  data  oase  environment,  and  the 
states  to  oe  monitored  for  can  oe  generated  by  several  users,  at 
different  points  in  time.  The  following  are  examples  ot 
possible  specifications: 


1.  "Report  any  cnecking  account  whose  oalance  is  unoer  ^200. 


2.  "Produce  a list  ot  pending  deliveries  for  a Client  who 
cnanges  his  aaaress." 


3.  "Issue  a warning  it  a salary  is  mocinea  to  be  lower  than 
before." 


"Report  any  department  wnere  tne  average  salary  is  over 
*1 5uu0 . " 


i 
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Notice  tnat  ail  examples  above  define  an  state  ot  the 
information  in  the  oata  base  and  an  action  to  be  taken  when  it 
is  reached. 

The  programs  that  monitor  tne  data  base  for  tne  presence  or 
tnese  states  are  called  alerters.  Alerters  are  expected  to 
exist  in  a real  time  environment  and  perform  its  functions  also 
in  real  time;  attention  shoulc  tnen  oe  paid  to  every  single 
uata  base  upuate,  tnus  imposing  a great  concern  on  efficiency. 

in  cruet  to  determine  it  a oata  Dase  update  results  in  one 
ot  the  specirieu  states,  conventional  systems,  by  ana  large, 
require  the  coding  of  auuitional  routines  specifically  tor  this 
purpose,  usually  written  in  an  application  language.  These 
routines  are  usually  built  by  application  programmers  with  no 
special  metnoooiogy  to  follow  in  the  design  task.  As  an 
expected  result  they  ate  expensive  in  ootn  Deinn  constructed  anu 
run,  ana  very  difficult  to  maintain,  tnev  consume  too  much 
manpower  anu  uo  not  yielu  results  of  tne  quality  tnat  couiu  oe 
expected  . 

as  an  step  tcwaru  tne  improvement  oi  this  situation  it  nas 
oeen  proposed  tnat  a set  ot  alerter  rules,  provided  by  the  uata 
case  administrator , are  placeu  unuer  the  responsioil ity  of  the 
oata  base  system  tor  tneir  maintenance  ana  execution.  This  set 
of  rules  can  be  expressed  in  terms  of  a relationaiiy  complete 
language,  in  a relational'  data  oase  (KL'd)  environment.  The  hign 
flexibility  ot  sucn  Kina  of  language  permits  the  processing  of 
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unanticipated  data  base  updates,  as  well  as  proper  care  of  the 
estaolisnea  set  of  rules  ana  their  application  to  tnese  updates. 

duneman  and  Morgan  define  an  alerter  as  a cond ition-pr op r am 
pair  where  the  condition  may  oe  any  predicate  involving  two 
consecutive  states  of  the  data  base  (3Umi  7a].  the  condition 
describes  the  state  of  the  data  that  will  be  monitored  for, 
while  tne  program  part  is  related  to  the  action  to  be  taken  when 
the  condition  is  satisfied.  An  alerter  should  be  able  to 
identity  certain  states  of  tne  information  when  they  were 
reacned  due  to  database  chances,  instead  of  detectinn  their 
presence  at  any  given  point  in  time. 

The  previous  point  may  be  maae  clearer  if  we  take  a look  at 
an  example.  Let  us  consider  the  following  command: 

"wotity  me  it  any  Philadelphia  account  falls  below  5UG‘- 

The  cojective  ot  tms  command  is  to  detect  the  presence  of 
the  state  oescriDed  oy  ••Philadelphia  account  < buu"  in  the  uata 
case;  while  also  indicating  tnac  tne  action  of  reporting  it  to 
tne  user  snoulu  be  performed  upon  its  detection. 

Cine  oovious  alternative  tnat  a given  user  nas  for  tne 
implementation  ot  this  command  would  oe  to  perform  this  cuerv  at 
a given  time  ano  ODtain  an  appropriate  answer.  On  tne  other 
hanu  tne  same  user  could  define  an  alerter  to  perform  the 
function.  Under  this  later  alternative  tne  data  case  manacenent 
system  would  have  a more  active  performance  being  capaoie  of 
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producing  valuable  information  tuat  has  not  been  specifically 
requested  by  a query.  In  addition,  instead  of  waiting  for  an 
user  generated  test,  in  many  cases  with  absolutely  no  regard  tor 
tne  origins  of  tne  condition,  an  alerter  would  test  for  tne 
presence  of  that  condition  in  tne  expected  moment  of  its 
generation . 


1.2.1  Simple  Alerters  - 


A distinction  between  simple  ana  complex  alerters  has  been 
presented  in  [BULL  75].  Let  us  assume  that  a cata  base  is  a 
collection  or  recoras,  eacn  of  tnem  belonging  to  one  record 
class,  anu  eacn  record  class  naving  a nunmer  of  component 
fields.  Using  tnis  assumption,  we  have  a simple  aier  ter  if  the 
condition  associated  to  it  is  specified  bv  means  of  exorcssions 
involving  constants,  a single  record,  and  fielcis  of  the  same 
recorc  class.  This  way  one  or  several  fields  in  an  arbitrary 
record  of  a given  recoro  class,  as  well  as  additions  and 
deletions  cf  recorcs  to  a class,  can  be  monitored. 


ACCOUNT  record  class:  ( ACCT  # , UAftE , LOCATION  , TYPE  , AiiGULT ) 


Figure  1.1:.  Examble  of  a record  class  showing  record  fields 
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Ueseu  on  tne  recoro  ciass  sncwn  in  r'lgure  1.1#  it  can  oe 
seen  tnat  the  roiiowing  ate  simple  alerters  placed  on  ACLOU.Vi . 
consider  tnat  it  was  uesirea  to  report  when: 

1.  An  account  tails  oelow  add. 

2.  The  location  ot  an  account  is  cnangeu. 

J.  An  account  ot  type  a lccateu  at  Denver  increases  its 
amount  ov  2000. 

4.  mere  is  a new  account  of  type  c. 
o.  A ittw  lor*  account  is  closed. 


A common  denominator  tor  tne  previous  examples  is  that  all 
involve  expressions  ano  tiems  of  ACcocnY  alone.  All  ot  tnem 
contora  to  tne  spec n icatiuns  given  aocve  tor  simple  alerters, 
as  tney  can  oe  expresseo  as  mod  n icaticns  (1,1,3),  additions  (4) 
ana  deletions  (b)  to  a single  recora  class. 


1.2.2  Complex  Alerters  - 

It  should  De  a frequent  case  tnat  a meaningful  aierter  lias 
to  oe  expressed  in  terms  of  several  record  classes 
simultaneously,  instead  ot  a single  record  class;  in  acoiticn 
it  may  also  be  ot  interest  to  derine  an  alerter  ter  a condition 
expressed  in  terms  of  more  tnan  one  record,  or  several  reccra 
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classes,  or  an  aggregate  oi  tne  information  ot  a given  record 
class.  Alerters  or  greater  complexity  than  tne  ones  uetined  in 
tne  previous  section  are  generated  this  way,  expressing 
predicates  tnat  coulu  not  oe  honjj.ee.  by  simple  alertino;  we 
will-  then  follow  their  uesignation  as  complex  aler  ter  s as  given 
in  IbUwL  7b). 

RLC oKO  CLA6S: 

1.  UBLK:  (IISLH#  , OS , CA'j'c,dol<j  , SCHOOL) 

2.  JobJ:  ( JOti # , USLR f , Si.v'i'OS  , DuKrtVlol* , Lj-.hVjuAOL  ) 

Figure  l.C:  bstk  and  JOBS  recoru  classes 

Consiaer  working  witn  aato  reiiectino  the  use  c l a computer 
center.  As  shuwn  in  ric.uie  1.1,  there  exists  an  USlk  recora 
class  wnicn  contains  information  aoout  users  ot  tne  computer 
facility,  it  nas  the  name  and  numoer  or  each  user,  nis  category, 
say  stuuent  or  tacultv  mernoei  , ano  the  school  or  origin?  mere 
is  also  information  aoout  each  loo,  in  tne  JoLB  recoru  class, 
wmch  snows  the  lob  ano  user  numoer,  whether  tne  30c  is  finisned 
or  not,  its  uuration,  sr.u  the  language  usea. 

baseu  on  tne  recoru  classes  uescribeu  acove,  we  can  now 
taxe  a Iook  at  several  examples  or  some  informally  cetmen  xinos 
ot  complex  alerters. 
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1.  "Report  any  faculty  member  using  ARL" . In  this  case  we 

are  describing  an  alerter  that  involves  more  than  one 

record  class  anu  reauires  certain  Knowledge  of  the  uetr. 

■ 

oase  structure.  The  condition  can  become  true  either 
because  a faculty  member  starts  usinc  ARL  or  because 
the  category  of  somebody  running  an  ARL  ]ob  is  changed 
to  that  of  faculty  member. 

k.  "Report  when  the  duration  of  the  active  jobs  average 
more  than  T" . Even  though  this  alerter  reouires  of 
only  one  record  class  to  worn  it  neecs  to  examine  a 
full  subset  of  it,  ratner  tnan  a single  record  as  wcula 
be  the  case  of  a simple  alerter. 

3.  "Report  any  user  that  runs  more  than  ten  jobs  in  a 
twenty  four  hours  period'-.  The  implementation  of  this 
alerter  would  require  the  maintenance  cf  accessible 
history  for  the  proper  evaluation  cf  the  predicate. 


All  three  examples  mentioned  above  represent  complex 
alerters,  respectively  sensitive  to  (1)  tne  structure  cf  the 
data  base,  (k)  data  aggregates,  ana  (3)  a time  or  transaction 
basis.  Tnese  ano  other  kir.os  of  complex  alerters  can  be 
expressed,  (monitoring  icr  tne  presence  ol  specific  patterns  in 
the  oata  base,  tor  example),  while  aiilerent  cegrees  of 
complexity  can  oe  expected  from  tne  standpoint  of  the  evaluation 
of  the  aata,  tneretcre  posing  tne  interesting  problem  of 


J 
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efficiently  nanaling  general  alerters. 


Tne  evaluation  of  tne  predicates  of  complex  alerters  may 
involve  significant  amounts  ct  uata  case  processing,  since  tne 
information  pertinent  to  an  alerter  may  not  exist  explicitly  and 
therefore  haa  to  De  evaluated,  frequently  requiring  costly 
computations.  Techniques  to  efficiently  evaluate  the  alerter 
predicates,  minimize  and  if  possible  avoid,  data  base 
recomputation  are  a necessary  component  of  an  efficient  alerter 
system.  Tne  details  of  an  implementation  of  these  techniques 
are  tne  suDject  of  this  tnesis,  ana  tney  wiii  be  discussed  more 
formally  aheaa. 


1.3  Integrity  Constraints  - <V  delated  Topic 


inere  are  several  topics  that  are  closely  related  to  the 
concept  of  alerters,  monitoring  aata  base  integrity  constraints 
cculu  perhaps  De  considered  tne  cioser  one.  A discussion  cf  a 
general  franeworx  for  semantic  integrity  is  given  in  [r.AMM  76], 
while  means  or  efficiently  aetectina  tne  violation  cf  data  base 
assertions  are  presented  in  [hAMI-i  77]. 

Using  alerter  terminology,  an  integrity  constraint  could  be 
said  to  be  comparable  to  an  alerter  wncse  programmed  action  was 
to  reject  any  data  base  modification  tnat  caused  its  associated 
predicate  to  be  true.  This  is  usually  approached  definina  a set 
of  assertions  about  the  integrity  of  tne  information  in  the  aata 
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Dase,  tnese  assertions  should  remain  true  permanently,  ana 
shoula  not  oe  vioiatea  by  data  base  upaates. 

Tne  major  distinction  oetween  alerters  ana  integrity 
constraints  resides  in  the  fact  that  we  may  be  interested  in 
defining  an  alerter  to  monitor  tne  data  base  for  a perfectly 
legitimate  state  wnose  presence  does  not  imply  any  error  or 
undesirable  situation,  while  tne  objective  of  an  integrity 
constraint  is  to  guard  the  data  base  against  illegal  situations 
and  reject  any  attempt  to  generate  them. 

It  coulo  be  said  that  an  integrity  constraint  deals  with 
the  potential  resulting  state  of  the  data  base  after  a 
modification  has  been  attempted,  if  this  state,  based  on  the 
defined  assertions,  is  tcuna  to  be  illegal  tnen  tne  modification 
would  be  rejected.  This  is  another  major  distinction  between 
alerters  ana  integrity  constraints,  wmch  can  be  considered  a 
consequence  of  tne  previous  one;  in  general  an  alerter  is  only 
interested  in  states  that  haa  net  been  detectea  oefo^e,  in  other 
words,  an  alerter  shcula  lcncre  a condition  of  tne  in  to rmat ion 
that  was  true  before  the  application  of  tne  update  that  is  bene 
evaluated.  It  can  be  seen  that  alerters  need  to  keen  track  of 
previous  detections,  (''involving  two  consecutive  states  of  the 
data  base",  quoting  from  the  definition  of  alerters  aiver 
before),  while  a similar  intearity  constraint  has  no  need  of 
this  kind  of  history  as  any  attempt  to  violate  the  assertion 
should  have  been  prevented. 
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As  an  illustration  of  the  previous  point,  suppose  that  we 
wanted  to  be  notified  whenever  somebody  reached  the  age  of  21, 
it  would  be  preferable  that  we  were  only  notified  of  those  cases 
that,  because  they  have  just  turned  21,  were  not  reported  in 
previous  instantiations  of  the  alerter. 


There  exists,  of  course,  a class  of  integrity  constraints 
that  has  to  be  defined  in  terms  of  consecutive  states  of  the 
information,  (salary  increases  have  to  be  of  less  than  20%,  as 
an  example  of  a simple  case),  nevertheless  these  states  are  used 
in  a different  frame  of  mind  since  the  assertion  needs  to  be 
expressed  in  terms  of  the  transition  of  the  information  itself, 
as  this  is  considered  the  actual  monitorable  event. 


Some  alerter  predicates  would  have  difficult  excression.  as 
integrity  assertions,  as  could  be  the  case  for  conditions 
involving  a seouence  of  transactions  or  a given  time  period. 
For  example,  consider  monitoring  a bank  data  base  to  "report 
those  accounts  which  maintain  a balance  under  $2GC  while  mere 
than  ten  checks  are  cashed”,  or  "report  those  accounts  whose 
balance  was  under  $100  at  closing  time".  The  problem  of  their 
implementation  as  integrity  constraints  would  reside  in  how  to 
perform  the  deferred  selection  of  the  transaction  to  be 
rejected,  and  while  they  might  lack  meaning  if  expressed  as 
integrity  assertions,  they  certainly  can  be  meaningful  alerter 
oredicates . 
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Alerters  do  not  have  a direct  effect  on  the  contents  of  the 
data  base,  while  this  is  not  the  case  of  integrity  constraints, 
as  a result,  several  problems,  in  particular  consistencv 
problems  in  a concurrent  user  environment,  are  less  critical  in 
an  alerter  implementation.  A discussion  of  an  implementation  of 
aspects  related  to  integrity  constraints,  and  general 
transaction  management  problems,  can  be  found  in  [A3TR  76],  In 
general  we  would  expect  alerters  to  be  able  to  express  a mere 
complex  class  of  predicates,  and  to  be  at  a higher  level  cf 
implementations  than  integrity  constraints. 
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RELATIONAL  DATA  BASES 


2.1  The  Relational  Data  Model 


In  a series  of  papers  Coda  introduced  the  relational  model 


of  aata  in  an  effort  to  helm  in  the  solution  cf  various  data 


base  management  Droblems  [CODD  70].  Some  of  the  objectives  of 


this  work,  as  stated  by  Codd , were 


to  provide  a simple  community  view  of  the  data 


3.  to  introduce  a theoretical  foundation  in  data  base 


4.  to  provide  the  user  with  a high  level 


noncrocecur ai 


data  sublanguage  for  accessir.q  dat 


The  relational  data  model  is 


1 model 


r epr esentir.q  relationshics  among  attributes  of  an  entitv  set  and 


the  association  between  entity  sets  [CCDD  7C ] 


Give 


EM  FLO  YE  E 


1 

EM  F # 

NAME 

SALARY 

DEFT# 

010 

JONES 

12000 

1 

02C 

SMITH 

15000 

1 

040 

ADAMS 

11500 

2 

060 

WILLIAMS 

12500 

1 

C 70 

SPENCER 

12C0C 

2 

060 

THOMAS 

14500 

1 

050 

DAY 

11000 

2 

Figure  2.1:  The  EMPLOYEE  relation 

From  the  user  point  of  view,  a relational  data  base 
management  system  organizes  and  maintains  the  data  according  to 
the  relational  data  model,  (This  does  not  imply  that  the  actual 
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file  structure  has  to  resemble  that  of  a table  or  any  similar 
rectangular  organization,  it  rather  implies  the  presence  of  the 
capability  to  handle  the  data  base  as  the  set  of  relations  as  it 
is  conceptualized). 

Since  relations  are  sets,  the  data  lanquage  provided  by 
such  system  has  to  be  capable  of  performing  all  of  the  usual  set 
operations,  (the  result  of  the  application  of  these  operations 
mav  not  be  a relation;  for  example  the  union  of  two  relations 
of  different  degrees  is  not  a relation).  We  will  restrict 
ourselves  to  those  operations  which  result  in  valid  relations. 
These  relational  operations  allow  an  user  to  create  new 
relations  based  on  existing  ones.  We  will,  refer  to  a relation 
existing  in  the  data  base  as  a base  relation;  every  other 
relation  derived  from  these  ones,  using  the  relational 
operators,  will  be  referred  to  as  a virtual  relation;  these  can 
either  be  combinations  or  subsets  of  the  base  relations. 


2.2  Relational  Algebra 

The  relational  operators  can  be  described  using  either  the 
relational  algebra  or  the  relational  calculus.  Co dd  defines  a 
set  of  high  level  relational  algebra  operations  and  shows  that 
this  set  is  relationallv  complete  [CCDC  72].  A lanquage  is  said 
to  be  relationally  complete  if  it  possesses  the  procertv  that 
any  relation  definable  bv  means  of  calculus  expressions  may  be 
retrieved  via  suitable  statements  in  that  lanquage. 


m 
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In  the  relational  algebra  mentioned  above,  we  have  two 
different  kind  of  operations:  traditional  set  operations  and 
special  relational  operations,  in  the  first  group  we  have  union, 
intersection,  difference  and  an  extended  Cartesian  nrcduct, 
while  in  the  second  group  we  find  projection,  join,  division  and 
selection . 

For  the  operations  union,  intersection  and  difference  the 
relations  involved  have  to  be  unicn-comoatible ; we  say  that  two 
relations  are  union-compatible  if  they  are  of  the  same  degree, 
and  the  ith  attribute  of  the  one  is  obtained  from  the  same 
domain  as  the  ith  attribute  of  the  other. 

1.  UNION (A, B):  The  union  of  two  compatible  relations  A 
and  B is  the  set  of  all  tuples  t that  belong  to  either 
A or  3. 

2.  INTERSECTION (A, B) : The  intersection  of  two  compatible 
relations  A and  B is  the  set  of  all  tuples  t that 
belong  to  both  A and  3. 

3.  DIFFERENCE (A, B) : The  difference  between  two  compatible 
relations  A and  B (in  that  order)  is  the  set  of  all 
tuples  t belonging  to  A and  not  to  B. 

4.  EXTENDED  CARTESIAN  PRODUCT (A, 3) : The  extended 

Cartesian  product  of  two  relations  A and  D is  the  set 
of  all  tuples  t such  that,  for  all  a belonging  to  A and 
all  b belonging  to  B,  t is  the  concatenation  of  a and 


b. 
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5.  PROJECT (A, X ) : A projection  of  a relation  A is  obtained 
selecting  some  specified  attributes  X,  from  A and 
eliminating  the  others,  the  duplicated  tudes  that 
might  appear  are  omitted  from  the  resultinq  relation. 

6.  JOIN (A, B, X, Y ) : If  two  relations  A and  B have  common 
attributes,  X in  A and  Y in  E,  they  mav  be  joined  over 
those  attributes;  the  result  of  this  operation  is  a 
new  relation  of  tuples  t created  as  follows:  if  two 
tuples  a and  b,  belonqinq  to  A and  B r espectivel v, 
share  the  selected  common  attributes,  they  are  joined 
together  into  a new  tuple  t formed  bv  the  common 
attributes,  the  remaining  attributes  of  a,  and  the 
remaininq  attributes  of  b. 

7.  DIVIDE (A, B, Y, 2) : Given  a binarv  relation  A and  an 
unary  relation  B,  "let  the  dividend  A have  attributes  X 
and  Y and  let  the  divisor  B have  attribute  2,  and  let  Y 
and  2 be  defined  on  the  same  underlying  domain.  Then 
the  divide  operation  - DIVIDE  A BY  B OVER  Y AND  2 
produces  a quotient  defined  on  the  same  domain  as  X;  a 
value  x will  appear  in  the  quotient  if  and  only  if  the 
pair  <x,v>  appears  in  A for  all  values  y appearing  in 
S"  (DATE  751. 
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8.  SELECT (A, X, nr ) : The  select  operation,  apolieo  to  a 
relation  A,  generates  a subset  of  A formed  by  those 
tuples  for  which  a specified  predicate,  involving  some 
attributes  X in  A,  is  satisfied.  In  order  to  avoid  any 
misunderstanding,  it  should  be  noted  that  SELECT  is 
being  used  in  the  sense  of  the  restriction  operation 
defined  in  [CODD  70],  since  in  the  data  sublanguage 
SEQUEL  the  same  term  defines  an  operation  similar  to 
PROJECT. 


J 


r 
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CHAPTER  3 

ALERTERS  IN  A RELATIONAL  DATA  BASE 


3.1  Terminoloqy 

The  problem  of  implementing  alerters  in  a relational  data 
base  environment  is  discussed  bv  Buneman  and  Clemons  in  their 
paper  [DUNE  76],  avoiding  recomputation,  martial  evaluation,  ana 
related  data  structures  are  among  the  topics  analvzed.  The 
development  o£  this  Thesis  and  the  terminology  that  will  be 
described  here,  were  based  on  the  ideas  presented  in  this  caner . 
The  general  relational  terminoloqy  that  will  be  used,  martially 
outlined  in  the  previous  chapter,  is  based  in  the  work  of  E.  F. 
Codd , his  original  paper  [COLD  70],  and  ICGCD  72]. 

Ue  will  know  as  base  relations  those  which  are  exnlicitly 
defined  in  the  data  base  schema,  every  other  relation, 
obtainable  from  these  by  means  of  relational  algebra  operations 
will  be  called  a virtual  relation.  A relation  with  an 
associated  alerter  will  be  known  as  a target  rel at  ion . A target 
relation  can  either  be  base  or  virtual  acccrdinq  to  the  alerter 


definition 
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Let  us  suppose  that  we  have  the  data  base  schema  shown  in 
Fiqure  3.1,  containing  information  about  suppliers,  oarts,  and 
an  indication  of  part  quantities  for  each  supplier.  Let  us  also 
suppose  that  the  part  name  should  be  reported,  for  any  part  for 
which  any  CTY  is  greater  than  500. 


DASE  P ELAT  ION : 
SUPPLIERS: 
PARTS : 

SUP -PART 


(SLPF 4 ,NANE, ADDRESS, CITY) 
(PART  * , PART  -NAME  , DLSCRIPTIC  N ) 
(SUPP* , PART  I ,LTY ) 


E loURL  3.1:.  Suppl  ler/Par  t ciata  oase  schema 


In  this  case 

SUPPLIER,  PARTS, 

ano  SUP 

-PART 

ate 

ail 

base 

relations 

as  tney 

explicitly  exist 

in  the 

date  oa 

so 

schema . 

On 

the  otner 

nand,  a 

virtual  relation 

named , 

say. 

VR, 

could 

be 

defined  in  such  a way  tnat  it  would  contain  the  names  of  those 
parts  for  wnich  the  mentioned  condition,  CTY  > 500,  is  true. 


< 

I 


Vk  can  oe  constructed  to  be  a target  relation,  using 
relational  algeora  operations,  in  the  followinn  way:  select 
those  tuples  of  SUP-PART  where  QTY  is  greater  tnan  500,  -join 
them  with  PARTS  using  PART#  as  the  common  attribute,  and  finally 
project  PART-NAME  from  the  result. 


I L 
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A directed  graph,  (describing  tne  generation  of  a virtual 
relation  from  a set  of  base  relations,  is  called  a construction 
cuagram.  A construction  diagram  snows  which  operations  are 
needed  to  create  tne  virtual  relation,  ana  imposes  a partial 
ordering  on  their  execution.  A construction  diagram  for  vrt  is 
shown  in  figure  3.2. 

Alerters  will  be  defined  to  monitor  the  contents  of  tne 
target  relations.  While  monitoring  these  target  relations,  an 
alerter  will  oe  looking  for  possible  additions  and  deletions  of 
tuples.  Tnese  target  relations,  if  virtual,  will  be  defined  by 
means  of  construction  diagrams,  and  it  necessary,  actually 
constructed  to  evaluate  a given  data  base  update.  We  will  then 
maka  a distinction  between  add-al  er  ter  s and  del  ete-al  er^ter  s : an 
ada-alerter  will  monitor  the  target  relation  lor  addition  of 
tuples  wniie  a oeiete-aler ter  will  uo  tne  same  lor  deletions. 

t'cr  two  consecutive  states  ct  a relation,  betore  and  after 
ueing  updated,  tuples  will  be  considered  auoed  or  celetec  as 
ind  icatea  by  an  speeiiieu  set  of  attributes,  in  other  words, 
auditions  or  ueleticns  will  be  identified  by  comparing  tne 
projection  of  tnose  attrioutes  fLom  the  final  state  against  a 
similar  projection  ol  tne  previous  one.  we  will  use  the  terms 
anu  03h  as  a snor t-notation  to  denote  respectively  addition 
and  deletion  indicated  oy  a set  of  attributes. 


r'i-gure  3.2: 


PA  AYS 


VK 


project  PAPi-.f.aL 


select  ^i’x  > joU 


join  on  PhKi # 


SuP-P.aKT 


figure  3.2:  A constr uction  aiaoraa  for  v/i 
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as  an  illustration  of  tne  preceding  point,  imagine  that  the 
address  ot  a given  supplier  has  ceen  modified  in  our  relation  of 
figure  3.1,  strictly  speaking  tne  resulting  tuple  is  a new  one 
tnat  uia  not  exist  before,  yet  we  can  oe  interested  in 
laentitying  auditions  to  tnis  relaticn  only  when  we  find  a tuple 
with  a 5Ut Pi  tnat  was  not  in  tne  relation  oefore. 

wnen  the  uata  case  reaches  an  state  wnose  occurrence  is 
oeing  monitored  for  oy  an  alerter  we  say  tnat  the  alerter  nas 
oeen  triggered.  As  a result  of  tnis,  some  action  will  take 
piace,  ranging  from  simple  reporting  to  more  complex  operations 
on  any  of  tne  existing  relations. 


3.2  Relational  Algebra  - Conceptual  Extensions 

In  a relational  data  base  environment  alerters  should  be 
expressed  in  terms  of  relations  and  relational  algeora 
operations  applied  to  these  relations.  Otner  than  the 
mrormation  pertinent  to  tne  construction  diagram,  it  should  oe 
our  goal  to  express  an  alerter  exclusively  in  relational  aigeora 
terms . 

itnen  defining  an  alerter  in  tnese  terms,  tnere  arc  a number 
of  virtual  relations  that  can  net  oe  constructed  usino 
exclusively  the  operations  described  in  chapter  2.  one  very 
common  ana  frequently  required  element  in  an  alerter  definition 
is  seme  arithmetical  expression  involving  one  tuple,  or  an 
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aggregate  ot  tuples  in  tne  relation.  Tne  algebra  detineu  in 
Chapter  2 ooes  not  possess  any  Kina  ot  ar  i thmet ical  operations, 
therefore  as  we  are  interested  in  maximizing  our  alerter 
aetinitior.  capabilities,  we  have  maoe  some  aaoitions  to  the 
relational  operators  tnat  we  will  oe  using  tram  now  on.  even 
tnougn  this  aauitions,  dv  all  means,  are  oniy  a suDset  ot  tne 
arithmetical  and  aggregate  operations  tnat  coula  oe  auaea  to  a 
relational  language,  we  feel  tnat  their  incorpor ation  to  our  set 
ot  operations  will  sensibly  broaden  the  application  range  ot  our 
alerters,  and  will  serve  our  purposes  as  to  characterize  tne 
treatment  tnat  snould  oe  given  to  similar  operations. 

«e  will  now  oetme  tne  operations  that  will  oo  adoeu  to  our 
relational  algeora  m a very  similar  way  to  that  of  Cnapter  ... 

rne  action  or  applying  any  or  tne  operations  m tms 
extenaeo  relational  algeora  will  result  m anot.ner  relation, 
wmcn , in  turn,  coulo  be  operateo  again  as  would  oe  reouireo  in 
a construction  aiaaram. 


i i 


1.  liA.MMliM  (A,  X)  : lne  maximum  ot  relation  t\  is  a tuple  tor 
wnich  a set  of  spec itieu  attributes  a has  the  maximum 


value  . 

2.  MI* IMUM  l A,  X)  : The  minimum  ol  relation  t\  is  a tuple  tor 
wmcn  a set  a specitieo  attributes  x has  tne  minimum 
val ue  . 
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3.i  AVLKhGL  ( A,  X)  :,  Tne  average  of  relation  A for  one  of  its 
numerical  attributes  a,  is  a tuple  containing  the 
average  ana  sun  of  tne  attribute,  and  a count,  for  the 
tupies  in  tne  relation. 

4.  ColiwT  (A,  A)  : Given  a relation  t\  ana  a set  of  attributes 
X,  tne  count  of  A is  a projection  of  a on  these 

attributes,  each  tuple  concatenated  witn  the  respective 
count  of  original'  tuples  in  A snaring  the  projected 
a ttr ibute  s . 

b.  SALrth  DORR  1UTALS  (A,  (X , l ) ) :.  Given  a relation  A,  a set 
of  attributes  X,  ana  a numerical  attribute  Y,  the  breaK 
down  totals  of  A is  a projection  or  A on  one  attributes 
X,  wnere  each  tuple  is  concatenated  witn  a count  and  a 
sum  of  1 for  the  original  tuples  in  A sharing 
attrioutes  X.  As  an  example  consider  tne  scnema  in 

Figure  3.1  ano  imagine  tnat  we  neeaea  to  obtain  the  sum 
of  QTY  for  each  t-ART#  in  SUPP-PART.  This  cculc  be 

specified  as  tne  br eaX-down- totai s of  QTY  in  SUPP-PART 
oy  PART#,  ( ohOWTOi (SUPP-PART, (QTY , PART ff ) ) ). 

b.  CHrtNGES  (A,  B,X,  Y ) Given  two  relations  A ana  3 , union 
compatible,  anu  a set  of  common  attributes,  X in  A and 
i in  u,  changes  is  equivalent  to  tne  JgI.n  operation, 
restricting  tne  result  only  to  those  tuples  wnere  there 
is  a difference  oetween  any  of  tne  correspondent 
ncn-common  attrioutes  of  A ana  3.  tve  will  use  this 


re! ation 


operation  to  detect  the  cnar.ges  suffered  uy  a 
since  ChAhGLS  will  use  consecutive  states  of  the 
relation  as  its  parameters,  (before  and  alter  upaates) . 
In  this  manner  we  achieve  the  capability  of  expressing 
alerters  to  monitor  transitions  of  the  data.  tor 
example:  “report  any  employee  transferee!  from  sales  to 

maintenance"  . 

how  tnat  we  have  complemented  tne  relational'  algebra  that 
we  will  be  using,  we  can  uefme  tne  tne  set  of  parameters  tnat 
ate  neeueo  in  our  implementation  ror  tne  proper  execution  of 
eacn  operation;  we  will  maxe  use  of  tne  following  list  for 
tneir  definition: 

OPLkrtTIuh  PArC>Mc.'ii_i\S 


1 . 

UtvlOiN  : 

rei-1 

9 

re^-1 ; 

2. 

bli xu.c  d : 

rei-1 

9 

tei-i; 

3. 

Ii>’i  RSC  i' : 

rel-i 

9 

rei-2 ; 

4 . 

XCPRUL)  :. 

rei-1 

9 

rei-2 ; 

5. 

PROJECT: 

roi-1 

9 

att-i ; 

b . 

kC  OUhT  : . 

rel-1 

9 

att-1 ; 

7 . 

A v'LkrtGE : 

rel-1 

9 

att-1 ; 

o . 

EsKOv.TOI  :. 

rel-1 

9 

att-1 ; 

*. 

MAXTuPL: 

r ei-i 

9 

att-1; 

It. 

Xl.vTliPL :. 

rei-1 

9 

att-1; 

11. 

Join  :. 

rel-1 

9 

rei-2 

m 


Page  2b 


12. 

Ci VIDE 

rel-1  , 

rel-2 

, att-1  , 

att-2 ; 

13. 

CHANGES 

rei-1  , 

rei-2 

, att-1  , 

att-2 ; 

14. 

SELECT 

rel-1  , 

att-1 

, fn  ; 

eacn 

ope  r ation , 

tins  list 

indicates  tne 

relations  it 

neeas  to  operate  properly,  ana  tne  sets  of  attributes,  it  any, 
that  are  required.  For  tne  SELECT  operation,  a conditional 
function,  tnat  operates  on  a tuple  at  a time  and  returns  a truth 
value,  has  to  be  oefmea. 


3.3  Some  examples  Ot  „;er te  r Definitions 

In  oroer  to  clarity  ideas  and  using  tne  terminology  that 
nas  oeen  descrioea  so  far,  it  could  oe  or  cenetit  to  present 
some  cases  of  different  alerter  definitions. 

It  is  our  intention  to  use  these  examples  as  tools  to 
introduce  several  cnar  acter  istics  of  tne  construction  diagrams, 
tnat  will  oe  part  of  our  implementation.  For  the  purpose  of 
defining  tne  contents  of  tne  construction  diagram,  we  will  maxe 
use  ot  a meta-language  to  express  the  operations  ano  necessary- 
related  information.  All  following  examples  will  be  based  on 
the  data  case  schema  depicted  previously  in  Figure  3.1. 

1.  "Keport  the  PAA'i'-wAi-lL  tor  any  part  tor  wnich  QT i > bdu  for 
any  supplier-'.  Tne  construction  diagram  for  tms  example 
was  shown  in  Figure  3.z,  ano  couic  oe  defined  as  follows: 
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define  alerter  mL1= 

monitor  tor  additions, 

indie  ateo  by  PARl-ulfti'iE , 
tnen  report; 
tarqet= 

project!  (PART-iwvfaE)  , 
select!  (QTT  > 5uU), 

join ( (PART* ) , (PARI s ) , 

PARTS , 

SLP— PART ) ) ) ; 

end ; 

In  this  case  AL1  has  been  detinea  as  an  ada-aierter,  where 


the  adaition  cf  tuples  will  be  indicated  by  the  detection  of 


new  PARI  -nAtibs  in  tne  target  relation. 


■Report"  is 


speciiiea  as  the  action  to  De  ta*en  it  one  alerter  is 
triggered,  (we  snail  see  that  this  is  tne  standard  alerter 


action,  wnich  prints  the  projection  cf  tne  "indicating" 


attrioutes  from  tne  acaed  tuples). 


Any  function, 


expressioie  oy  means  of  display  ana  relational  operations, 
can  be  defined  to  be  tne  action  associated  with  tne  alerter, 
finally,  the  target  relation  is  berinea  in  terms  of 
relational  ooeraters  and  tne  existing  case  relations. 


If  we  consider  tne  following  aierter  definition: 

define  alerter  AL2  = 

r.  onitor  for  additions, 

indicated  by  PARI -n AM E , 
tnen  report? 
target^ 

se iec t ( ((* i’ I > 500), 

join ( (PART*) , (PARTS) , 

! , PARTS , 

£ UPP-t ART ) ) ; 


Based  cn  our  previous  definition  of  addition  and  deletion  cf 
tuples  as  indicated  by  a set  of  attributes,  ASA  and  DSA,  AL2 
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, 'll"' 


is  equivalent  to  AL1,  with  the  aaded  advantage  of  having 
omitted  one  step  in  the  construction  of  the  target  relation. 


'•Report  the  supplier  RAM  £ and  PAKT-i.AilE  ter  new  parts  in  the 
list  of  any  supplier".  1 is  alerter  could  be  defined  as: 


define  alerter  AL3= 

monitor  for  additions, 

indicated  by  RAM E , PARI -RAM E , 
tnen  report; 
target= 

join  ( (SUPPs ) , ( S U PP  # ) , 
join  ( ( PARI # ) , (FAR'D?)  , 
PARIS , 

SUP-PART)  , 

SUPPLIER) ; 

end  ; 


It  we  observe  that  pieces  of  AL3  are  shared  by  the 
previous  two  alerter  definitions,  it  should  be  possible  to 
define  them  as: 


define  node  i\'Dl  = 

join  ( ( FARTff ) , (PARI#)  , 
PARIS , 

SUP-PART) ; 

end ; 


ana 


define  alerter  AL3= 

monitor  for  additions, 

indicated  by  LAME, PART -nAME, 
then  report; 
target= 

loin ( (SUPP#) , (SUFP# ) , 

ND1, 

SUPPLIER) ; 


end ; 


AL1  and  AL2  should  then  be  modified  accord  inaiy.  It 
should  be  no  tea  that  rather  than  a simple  ease  of 
expression,  the  goal  cf  this  nede  definition  is  to  allow  the 


L 


u 


more  than  one  alerter,  besides  savings  in  the  construction 
diagram  representation,  it  would  be  translated  into  adceo 
efficiency  since  if  a given  virtual  relation  had  to  be 
constructed  tor  more  than  one  alerter,  it  would  only  have  to 
be  done  once.  In  the  following  example  we  show  how  AL2 
could  be  modified  as  an  example  of  an  action  different  than 
••  report"  . 

define  alerter  mL4= 

monitor  for  aaoitions, 

indicated  oy  PARI -dam E , 
then  print(join( (bUPP* ) , (SUPP# ) , 
target , SUPPLIER ) ) ; 

target= 

sel ec t ( (QTi  > 50 u ) , 

UD1)  ; 

eno ; 

We  define  this  way  an  alerter  similar  to  AL2,  since  they 
only  airier  in  tnat  AL4  executes  a different  action  when  tne 
alerter  is  triggereo.  In  this  case  tne  contents  of  the 
whole  target  relation  are  processed  by  a join  operation, 
wnose  result  will  be  tne  printed  data.  ibis  is  only  a 
trivial  example  of  an  action  different  from  reporting 
associated  to  the  alerter,  wnich  is  expressed  in  relational 
algeora  terms. 


3.4  Avoiding  Recomputation 


A data  Dase  update  can  generate  major  changes  to  tne 


contents  of  uhe  relations  to  wnich  it  is  applied,  never tneless , 
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it  can  have  absolutely  no  effect  on  a target  relation,  even  if 
tne  target  is  expressed  in  terms  of  tne  updated  relations, 
furthermore  it  coulo  oe  the  case  that  even  thouqh  the  target 
relation  a iu  get  modified,  tne  modification  was  irrelevant  to 
the  associated  alerter,  since  the  alerter  was  only  deiined  to 
monitor  either  auditions  or  deletions. 

Certain  data  base  update  can  oe  recognized  to  be  of  no 
relevance  to  the  existing  alerters  without  having  to  examine  the 
contents  tne  uata  base,  we  will  refer  to  them  as  reao il y 
io_norabie  u^aat  e s , Kid's,  ( b UK  L 7b  J.  This  can  be  achieved  by 
comparing  the  characteristics  of  the  update ,( relations  involved, 
whether  it  was  an  addition  cr  a deletion,  ana  the  fields 
involved  it  it  was  a tuple  update) , with  the  character istics  of 
those  upuates  considered  to  be  potentially  relevant  to  the 
existing  alerters;  it  no  coincidence  is  found,  then  the  update 
is  considered  a Rib. 

tor  each  case  relation  and  the  alerters  in  which  they  are 
involved,  tne  set  ot  potentially  relevant  upuates  can  be  defined 
ov  examining  the  target  relations  and  the  operations  neeaea  to 
construct  them,  ana  will  be  specified  in  terms  of  the  relevance 
to  the  alerter  of  additions,  deletions  and  modification  of  each 
attribute.  'inis  set  can  oe  represented  as  a vector,  nencefortn 
known  as  relevance  vector  [dlluti  Vo], 


— — 
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he  will  cefine  a relevance  vector  as:  tor  a relation  oi 
degree  n,  involved  in  an  alerter  definition,  a vector  ot  length 
n+2  will  be  known  as  its  relevance  vector  ii  it  is  sucn  that: 
(i)  tne  tirst  Dit  is  set  to  one  it  auuition  ct  tuples  can  be 
relevant  to  the  alerter;  (ii)  the  second  bit  is  set  to  one  if 
deletion  ot  tuples  can  relevant  to  the  alerter;  (iii)  tor 
k*  > 2,  the  kth  bit  is  set  to  one  it  a modification  to  tne 
(k-2)tn  attribute  can  oe  relevant  to  the  alerter. 

As  an  illustration  let  us  consider  the  example  »3  ot  the 
previous  section.  Alerter  AL3  has  tne  following  construction 
u lag  r am : 

AL3:.(  ino  icated  oy  hAiiE , PART -wAfriL ) 
join  on 

join  on  PART# 

PAfv'iS  bUP-PAAT  SLPPLIi-K 

vine  relevance  vectors  tor  tne  relations  PAKVj , Sup-PAkY, 
and  SUPPLIER , reflecting  their  use  in  AL3,  are:  (1  U 1 1 U), 
(1  0 1 1 o),  ano  (1  o i 1 0 0),  respectively.  'iney  indicate 
that  only  addition  ot  tuples  to  the  relations  ano  modifications 
to  the  attributes  SUPP#,  PART#,  ana  PaRT-uAhE,  can  oe  ct 
relevance  to  the  alerter*,  while  modifications  to  uLobnIPTIo.. , 
UTY,  ALOKLos,  ana  CITY  can  not  pcssioly  modify  tne  tercet  in  a 
way  of  interest  to  aL3. 


i 


j.S  Partial  [.valuation  Using  The  Construction  Diagram 

We  nave  said  that  a aata  base  upoate  can  be  recocnizea  as  a 
Rlu  without  any  reference  to  tne  contents  of  the  data  base.  On 
tne  other  har.u , if  an  update  can  not  be  recognizee  as  such,  the 
construction  oi  the  virtual  relations  needed  to  evaluate  the 
target  nas  to  be  started  in  oruer  to  determine  how  it  is 
affected  by  tne  update.  nevertheless,  after  some  cf  the  virtual 
relations  have  been  constructed  ana  examined,  it  can  be  possiole 
to  conclude  that  the  upoate  will  not  affect  the  target  in  a 
relevant  way,  ano , therefore,  no  lurtner  evaluation  is 
necessary.  As  an  example,  let  us  consider  that  we  have  defined 
a target  relation  as  follows: 

target= 

io  inf  (SuPtfr)  , (SUPt s ) , 
select ( (UTf  > 5uo ) , 

S UR -PART)  , 

S U P P L I £.  i\ ) ; 

Accoroing  to  this  target  definition,  tne  modification  of 
the  attribute  tfTT  in  a tuple  or  SUP-PAki  can  .not  oe  consider eo  a 
KIu  to  any  aoo  or  delete-alerter  associated  to  the  target.  In 
addition,  let  us  also  suppose  that  the  aiettet  was  defined  as  an 
add-alerter,  according  to  bUPr»  anu  Pnk'i*f,  ano  that  a given  Q!  1 
is  modineu  to  be,  say,  hoO;  after  the  left  portion  of  the 
construction  diagram,  corresponding  to  tne  select  operation,  has 
been  evaluated,  it  is  possible  to  observe  tnat  since  no  tuole 
has  been  auoed  to  tne  virtual  relation  at  tnis  node,  it  will  not 
be  possible  tor  one  tc  be  auued  to  the  tercet  as  a result. 
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in  tne  following  Chapter  we  will  aiscuss  the  details  of  our 

implementation  of  tne  functions  to  aetect  klu‘s  ana  pericrm 
partial  evaluation. 
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ChAPTER  4 

IMPLEMENTATION  DETAILS 


4.1  Introduction 

The  present  Chapter  uescriDes  the  algorithms  and  data 
structures  that  were  used  to  implement  the  icieas  we  have 
discussed  so  tar.  The  Alerter  was  implemented  in  the 
DECS iSTEM-1 0 computer  at  the  Wharton  Scnool  of  The  university  of 
Pennsylvania,  using  the  POP-lU  programming  language  (3URS  71], 
[DA VI.  74 J.  In  tnis  implementation  tne  relations  are  processed 
as  a list  of  tuples  whose  heaa  contains  a definition  of  tne 
relation  name,  numoer  ana  characteristics  of  the  attributes,  ana 
tne  functions  to  handle  them.  Each  tuple  is  stored  as  a 
POP-record  structure.  The  purpose  of  the  programs  was  not 
primarily  to  nanole  a relational  data  base,  but  to  explore  the 
techniques  described  here. 
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4.2  Computing  The  Relevance  Vectors 

when  an  alerter  is  defined  it  is  inuicatea  whether  it  will 
De  an  acia-alerter  or  a delete-alerter  , anc  according  to  which 
attributes  .the  addition  and  removal  of  tuples  will  be 
recognized,  therefore,  a relevance  vector  reflecting  the  alerter 

i 

definition  can  be  assigned  to  the  target  relation.  In  doing  so 
we  would  achieve  the  capability  to  detect  additions  and 
deletions  to  the  target,  and,  if  any,  whether  they  are  relevant 
or  not;  in  order  to  accomplish  this  detection  the  contents  of 
the  target  relation  should  be  available. 

One  of  our  main  concerns  is  to  minimize  the  number  of 
occasions  in  which  we  need  to  construct  the  virtual  relations. 
Using  the  construction  diagram,  the  sooner  we  detect  that  an 
update  will  not  influence  a target  relation  in  a meaninoful  way, 
then,  as  a result,  the  number  of  virtual  relations  that  have  to 
be  constructed  will  accordingly  be  smaller.  This  minimization 
can  be  assisted  by  the  inspection  of  the  relevance  of  each 
intermediate  step  in  the  construction  of  a virtual  relation, 
since  a relevance  vector  can  be  assigned  to  all  the  relations  in 
a construction  diacram,  based  on  the  relevance  vector  of  the 
target . 

We  shall  now  describe  how  the  relevance  vector  is  commuted 
for  each  node  of  the  construction  diagram.  First  we  will  define 
partially  the  data  structure  associated  to  each  node. 
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1.  PRE(n):  A list  that  indicates  which  nodes  are  located 
immed  ia  tely  below  n in  the  construction  diagram,  and 
contain  the  relations,  operands,  that  should  be  handled 
by  GPR(n)  defined  below.  The  length  of  this  list  can 
either  be  one  or  two  depending  on  whether  OPR  (n)  is  an 
unary  or  a binary  operation;  in  the  case  that  the  node 
is  associated  to  a base  relation  PRC(n)  will  be  assumed 
to  be  null. 

2.  OPR(n):  A list  defined  the  following  way:  (i)  RATOR: 
the  head  of  the  list,  will  contain  the  extended 
relational  algebra  operation  needed  to  construct  the 
relation  associated  to  this  node;  if  the  node  is 
associated  to  a base  relation  a base  relation  signal 
will  take  this  dace  to  indicate  it;  (ii)  MTR:  the 
tail  of  the  list,  will  contain  a list  of  the  attributes 
that  will  be  used  by  the  operation,  for  each  relation 
in  the  nodes  in  PRE(n);  this  list  will  be  null  for 
base  relations  and  traditional  set  operations. 

3.  RLV(n):  The  relevance  vector  associated  to  this  node, 
will  indicate  the  relevance  of  the  updates  applied  to 
this  relations. 

4.  ECV(n):  Contains,  for  each  element  in  FRE(n),  a list 
of  the  correspondence  between  the  attributes  of  each  of 
them  and  the  attributes  of  r;  this  correspondence 
indicates  from  which  attributes  of  the  operands  are 
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taken  the  attributes  of  the  result. 


' 


For  a given  node  n,  the  relevance  vector  for  each  node  in 
PFE(n)  can  be  determined  based  on  RLV(r)  and  OPR(n),  (relevance 
vector,  operator,  and  attributes  of  the  ooerands) . The  table  of 
Figure  4.1  shows,  for  the  comparison  of  two  consecutive  states 
of  a relation:  (i)  what  kinds  of  updates  to  the  operands  can 
cause  additions  of  tuples  to  the  result;  (ii)  what  kinds  of 
updates  to  the  operands  can  cause  deletions  of  tucles  fron  the 
result;  and  (iii)  what  kinds  of  urdates  to  the  ocerands  can 
cause  alteration  in  the  contents  of  the  attributes  selected  to 
control  addition  or  deletion  of  tuples,  ASA  and  DSA. 

Using  the  rules  in  this  table,  we  can  define  a function  to 
compute  the  relevance  vector  of  the  nodes  in  the  construction 
diagram  of  a target  relation.,  in  general,  of  any  virtual 
relation  in  a construction  diagram.  Therefore,  we  now  define 
the  function  RLVCOMP  to  operate  on  a qiven  node,  N,  and  a 
relevance  vector,  RLVL ; it  will  also  make  use  of  the  function 
RULES  which  will  apply  the  rules  in  the  table  ar.c  will  operate 
on  OPR(N),  RLV(N),  ECV(N)  and  an  indication  of  whether  the  rules 
are  being  applied  to  the  first  or  second  eperanj,  if  there  is  ? 
second  one.  RULES  will  compute  3 relevance  vector  for  each  rode 
in  ?RE(N),  while  RLVCOMP  will  use  them  to  update  FLV  in  all  the 
nodes  in  the  construction  diagram  reachable  from  the  initial 
node  N.  RLVCOMP  can  recursively  be  defined  as  follows: 


* 


Figure  4.1: 


OPERATION 

EFFECT  ON 

THE  RESULT 

CHANGES  TO 
THE  OPERAND 

UNION 

a 

a,.n(l) 

(both  operands) 

d 

d,nti(l) 

IT*  * 

m(l ) 

INTRSCT 

a 

a ( 0 ) 

(both  operands) 

d 

d,m(0) 

m* 

n(l ) 

DIFRNCE 

a 

a,-n(0) 

(left  operand) 

d 

o ,ni  ( 0 ) 

m* 

XT  ( 1 ) 

DIFRNCE 

a 

d,m(0) 

(rigth  operand) 

a 

a,m (0 ) 

m* 

m(l) 

PROJECT 

a 

a,n>(2) 

d 

d,m(2) 

m* 

-Tl(l) 

JOIN 

a 

a,.n(l) 

d 

d,n(l) 

iS(l) 

SELECT 

a 

a ,m  (2 ) 

a 

d,.n(2) 

m(l) 

DI VI DE 

a 

a , m ( 0 ) 

(left  operand) 

d 

a ,m  ( 0 ) 

m* 

m (1 ) 

DI  VI  DE 

a 

d ,m  (2) 

(right  operand) 

c 

a, in  (2) 

;71* 

non-appl . 

XC  PROD 

a 

a 

(botn  operands) 

d 

d 

m* 

ffl(l) 

(continued) 
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(continued  from  previous  page) 


OPERATION 

EFFECT  ON 

THE  RESULT 

CHANGES  TO 
THE  OPERAND 

RCOOcJT 

a 

a,m(2) 

d 

d ,iii  ( 2 ) 

m* 

a ,d  ,m ( 1 ) 

AVERAGE 

a 

non-appl . 

c 

non-appi  . 

m* 

a ,d  ,m  ( 2 ) 

MAAi'OPL 

a 

a , m ( 2 ) 

a 

o,n(2) 

m* 

m ( 1 ) 

i-HwTOr'L 

a 

a,x( 2) 

d 

d ,m  (2 ) 

ra* 

n ( 1 ) 

SrOwTOT 

a 

a ,m  ( 2 ) 

U 

d,m{2) 

m" 

a , u , m ( 1 ) 

Cht\iVoLiS 

a 

m ( o ) 

(ootn  operanas) 

a 

d,m( J) 

X" 

m(l ) 

Meaning  of  tne  aynbois: 

a : audition  of  tuples. 

o : deletion  of  tupies. 

x*  : modification  of  one  of  tne  " ind  icating-'  attributes 
of  tne  result. 

m(U):  modification  of  any  of  the  attributes  of  the 
operand . 

m(l):  modification  of  the  attributes  of  the  operand  that 
correspond  to  tne  "indicating"  attributes  of  the 
result. 

m(2):  modification  of  the  attributes  of  the  operand 
involved  in  the  operation. 


Figure  4.1:.  Rules  for  computing  the  relevance  vectors 
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function  RLVCCMP  N RLVL  ; 

RLV  (N  K-RLV  (N  ) or  RLVL; 

X < - 1 ; 

for  each  Y in  PnC(N)  do 
beg  in 

RLVCOM  P ( Y , RULES  (OFR  (M  ) ,F-LV  (N  ) ,EPV  (N  ) , X)  ) ; 
Xs-x+l ; 
end ; 
end ; 


When 

an  alerter  is  placed  on 

a 

target 

relation. 

the 

f unction 

RLVCCMP  is  called 

using 

as 

oar  ameter  s 

the 

node 

assoc  iated 

to  the  target,  and  a 

relev 

ance 

vec  tor 

which 

ha  s 

the 

first  or  second  bit  set  to  one,  depending  on  whether  we  want  to 
monitor  additions  or  deletions,  while  each  one  of  the  rest  of 
the  bits  are  set  if  we  want  the  ASA  or  DSA  Detection  to  be  done 
according  to  the  corresponding  attributes. 


4.3  Partial  Evaluation 

We  will  now  comolete  the  definition  of  the  data  structure 
associated  to  each  node  of  the  construction  diagram  as  needed  to 
efficiently  perform  partial  evaluation. 

1.  DIF(n):  For  base  relations,  a vector,  similar  to  the 
relevance  vector,  indicating  the  changes  that  were  made 
to  the  relation  by  an  update.  The  presence  of  a bit 
whose  value  is  one  indicates  that  an  addition, 

deletion,  or  modification  to  the  cor rescord ina 

attribute,  affected  at  least  one  tucle  of  the 
assoc  iated  relation. 
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2.  POST(n):  A list  of  all  the  nodes  above  n in  the 

construction  diagram;  it  is  possible,  as  we  mentioned 
before,  that  these  nodes  belonar  to  different  alerters 
since  coctions  of  the  construction  diagram  can  be 
shared  by  more  than  one.  Each  element  of  this  list  is 
formed  by:  ( i ) PS:  the  node  above;  and  (ii)  RL:  the 
relevance  vector  of  node  n as  computed  with  rescect  to  1 

i 

the  relevance  vector  of  the  node  indicated  by  the 
related  PS.  (It  shoulu  be  noted  that  this  relevance  is 
different  from  RLV(n)  , even  thouch  the  latter  is  the 
logical  or  of  the  PL  relevance  vectors  in  P03T(n)  ). 

3.  CNT(n):  The  contents  cf  the  relation  associated  to 
this  node.  While  the  target  relation  is  beino 
evaluated,  the  contents  of  both,  previous  and  actual 
states  are  reflected  here. 

4.  ALT(n):  An  alerter  indicator;  if  this  node  is 

associated  to  a target  relation,  it  is  so  indicated  by 
the  number  that  identifies  the  associated  alerter, 
otherwise  it  is  mere. 

5.  FLAGn(n):  Three  binary  flags  with  the  fcllovina 

functions:  (FLAG1)  to  prevent  alerter  evaluation  from 

beir.a  performed  twice,  because  mere  than  or.e  relation 
was  affected  by  an  update;  (FLAG2)  to  avoid  double 
evaluation  of  the  new  contents  of  a virtual  relation; 
and  (FLAG3)  to  avoid  double  evaluation  of  the  old 
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contents  of  a virtual  relation. 

6.  MSG(n):  For  target  relations,  either  a messaoe  to  be 
printed  it  the  alerter  is  triggered,  or  instead, 
because  ot  the  sane  reason,  a function  to  be  executed. 
This  function  can  be  defined  in  anv  terms  of  our 
extended  algebra  and  involve  any  virtual  or  base 
relation  existino  at  the  moment. 


Figure  4.2  shows  the  definition  and  construction  diagram  of 
the  alerters  AL1  and  AL2.  A portion  of  this  construction 
diaaram  is  shown  in  Figure  4.3,  where  the  data  structure  defined 
above  is  detailed.  It  is  assumed  that  the  alerters  have  just 
been  oefined. 

These  alerters  are  the  expression  of:  (i)  AL1:  report 
NAME  and  FAKT#  for  the  suppliers  where  OTY  is  more  than  500,  for 
any  part;  and  (ii)  A L 2 : report  the  SUPP#  of  any  new  suoclier. 
The  set  of  potentially  relevant  updates  for  SUPPLIER  is  formed 
by  those  transactions  that  generate  addition  of  tuples  and/or 
modification  to  either  SUPF#  or  NAME,  since  those  updates  can 
result  in  the  triggering  of  one  of  the  alerters  defined  above; 
this  set  is  reflected  by  the  relevance  vector  RLV (SUPPLIER) , 
which  is:  (101100).  On  the  other  hand,  only  addition  of 
tuples  or  changes  to  the  CUPP  1 can  bo  relevant  to  AL2,  while, 
add  itionallv , modification  of  the  NAME  can  be  relevant  to  AL1; 
this  is  reflected  on  the  RL  vectors  in  POST (SUPPLIER ) . Finally, 


Fiqure  4.2: 


define  alerter  ALl  = 

monitor  for  additions, 

indicated  'ey  SUPP#, PARTS 
then  report; 
tarqet  = 

join  ( (SUPPif ) , (SUPP*)  , 
select! (QTY  > 500)  , 
SUP-PART)  , 
SUPPLIER) ; 

end ; 


define 


end  ; 


alerter  AL2  = 
monitor  for  additions, 
indicated  by  SUPF#, 
then  report; 
target  = 

pro j ec t ( (SUPPS ) , 
SUPPLIER) ; 


ALl:  join  on  SUPPs 


select (QTY  > 5u0) 


AL2:  project  SUPPS 


SUP-PART  SUPPLIER 


Figure  4.2:  Definition  ana  construction  aiaaram  for  ALl  and  AL2 


J 
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CPR ( AL2 ) indicates  that  the  first  attribute  should  be  projected 
from  SUPPLIER,  while  EQV(AL2)  shows  that  the  only  attribute  of 
AL  2 correspond  to  the  first  one  of  its  ooerand. 


In  order  to  properly  update  the  relevance  vectors  in 

POST(n),  the  procedure  RLVCOMF  has  to  be  rewritten  as  shown 

below,  consequently  needing  the  use  of  a dummy  parameter,  (nil), 

when  it  is  called  for  a target  relation. 

function  RLVCOMP  N RLVL  ANCS; 
if  ANCS.null  then 

ALT  (N  ) <-a.ler  ter  number; 
else  for  X in  POST  (N)  such  that  PS  (X)  *ANCS  do 
RL  (X ) <-RL (X ) or  RLVL ; 

RLV  (N  ) <-P.LV  (N  ) or  RLVL; 

X<-1 ; 

for  each  Y in  FRE(N)  do; 
beg  in 

RLVCOMF  (Y, RULES  (OFF.  (N)  ,RLV(M)  , EQV  (N)  ,X)  ,ANCS)  ; 
X<-X  +1 ; 
end  ; 
end ; 


We  have  said  that  target  relations  can  be  evaluated  using 
the  construction  diagram;  in  general,  the  contents  of  a virtual 
relation  associated  to  a node  in  the  construction  diagram  can  be 
evaluated  using  the  next  recursive  function,  which  operates  on  a 
given  node  in  the  construction  diagram,  and  returns  the  contents 
of  the  virtual  relation  associated  to  the  node, 
function  EVAL  N; 

if  RATOR(N)  is  base  or  FLAGx(M)  then 
return  C1N  (N ) ; 

FLAGx (N ) <-l ; 

for  each  X in  PRE(M)  do 
stack  EVAL (X ) in  EEL; 

for  each  Y in  AT  TP.  (N ) do 
stack  Y in  AIR; 

return  acply (RATCR (N ) , (R£L, ATK ) ) ; 
end ; 


REL  and  AIR  store  temporarily  the  operands,  (relations  and  their 
attributes),  that  will  be  used  by  RATOR(N). 

In  the  actual  implementation  of  the  function  EVAL,  the 
second  attrioute  of  the  relational  operation  CHANGES  is 


consiaered 

to  be  making 

reference 

to 

tne  old 

contents 

of  a 

relation, 

1 .e . , tne 

state  of 

the 

relation 

prev  icus 

to  tne 

update.  This  way  we  can  use  this  operation  to  express  a class 
ot  alerter  predicates  baseo  consecutive  states  of  the 
information  in  tne  tuples.  As  an  example:  “report  any  change 
of  salary  wnere  the  new  salary  is  less  than  the  old  salary". 

Before  going  any  further,  we  would  like  to  introduce  the 
notion  of  transaction.  For  the  purpose  of  this  thesis,  we  will 
consider  as  a transaction  to  a logically  related  set  of  data 
base  uouates,  which  has  the  characteristic  of  deferring  the 
evaluation  of  the  alerter  until  its  complete  application.  r’or 
example,  in  an  employee-aepar tment  data  case  we  coulo  nave 
defined  an  alerter  to  report  all  departments  without  managers, 
and  anotner  alerter  to  report  all  employees  wno  do  not  belong  to 
an  existing  department.  If  we  are  in  a situation  wnen  a 
department  is  oeinq  created,  and  information  for  new  employees 
is  oeing  loaded,  including  that  of  tne  department  manager,  it  is 
oovious  that  any  attempt  to  insert  the  manager  tuple  without 


depa r tment 

information , 

o r 

vice  versa 

, will  leaa  to 

tne 

tr igger ing 

of  one  of 

tne 

al  er  te  r s . 

vie  could  execute 

the 

creation  of  a new  department  as  a transaction,  including  tne 


t'aae  oU 


aadition  of  the  department  tuple  and  tne  addition  of  tne  manager 
tuple,  after  wnich  the  alerter  evaluation  could  De  performed. 
From  now  on  we  will  consider  tnat  tne  data  case  is  oeing  updated 
oy  transactions,  and  will  use  tne  terms  updates  and  transactions 
indistinctly  to  refer  to  data  case  modifications. 


Data  base  updates  can  take  the  rorm  of  additions  or 
deletions  of  tuples,  or  modification  of  their  attributes.  As  a 
consequence  of  tne  application  of  a transaction  to  the  data 
base,  the  oirference  vector,  DIF,  of  tne  nodes  corresponding  to 
the  mooiried  base  relations  are  updated  to  reflect  tne  change 
that  was  made.  For  a modified  relation,  if  a tuple  was  adoeo 
and/or  deleted,  bits  one  and/or  two  are  respectively  set  to  one, 
and  if  for  some  tuple  the  kth  attribute  was  mooified,  then  tne 
oit  k+2  is  set  to  one. 


Kid's  can  oe  now  identified  oy  direct  comparison  of  the 
relevance  and  difference  vectors  for  each  case  relation;  It  tne 
logical  and  of  tnese  two  vectors  does  not  contain  a one,  tnen 
tne  transaction  is  a Rid. 


In  order  to  allow  the  processing  of  the  case  relations  as  a 
group,  the  nodes  associated  to  them  will  bo  joined  in  a list. 
The  following  function,  TRANd-DVAL,  will  operate  on  tnis  list, 
and  will  start  the  evaluation  of  the  alerter  if  the  uodate  is 


f l 

i 


[ 
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function  TRANS -EVAL  BASELIST; 
for  each  X in  BASELIST  do 

it  (kLV(a)  ana  DIE(X))  contains  a one 
ALERT -E  VAL  (X)  ; 

enu ; 


then 


unce  it  is  determined  tnat  a transaction  is  not  a HIU,  tne 
function  ALERT-E VAL  will  evaluate  the  effect  of  tne  update  ana 
eventually,  if  it  is  found  relevant  will  trigger  tne  appropriate 
alerter.  Tne  function  ALEKT-oVAL  can  oe  defined  as  follows: 


function  ALERT-EVAL  u; 

CTN (N ) <-  BOTh-L VAL (W } ; 

it  not  ( r'LAGl  (W  ) ) ana  CHANGED  (CTN  (A)  , RLV  (a  ) ) then 
if  target (N)  tnen 
tr  igger  (ln  ) ; 
else 

for  each  X in  POST(d)  do 

if  ChANGCO (RS (a ) , RL (X ) ) tnen 
ALERT-EVAL  (RS  (X  ) ) ; 

f LAG1  (NO  <-l ; 
ena ; 


Tne  function  i3GTu-EVAL  evaluates  the  contents  of  tne 
previous  ana  actual  states  of  the  relation  associated  to  a, 
using  functions  equivalent  to  tne  function  L\ML  aescrioed 
oefore.  Tne  function  CRINGED  taKes  tnis  result  ena  Dasec  on  a 
related  relevance  vector  aetermines  it  tne  changes  are  relevant, 
according  to  tne  indicated  attributes  and  tne  first  two  bits  of 
tne  vector,  (aaaition  ana  deletion  relevance).  When  the  changes 
are  touna  to  be  relevant  ana  tne  node  is  associated  to  a target 
relation,  the  relatea  alerter  is  triggereu;  if  a luncticn  is 
specified  in  nSG(N)  then  it  is  executea,  ctnerwise  iiSG(.v)  is 
printed  as  tne  stanaara  action,  together  with  tne  auditions  or 
deletions  that  triggered  tne  alerter.  It  tne  changes  are 


and  ALLLT-LVAL  would 
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ChAPTEK  5 

SUMMARY  .u*D  OUi^C  LbE  loi. 


In  this  Tnesis  we  have  described  tne  algorithms  that  were 
usea  in  an  implementation  ot  multiple  alerters  in  a relational 
environment,  winch  efficiently  monitor  tne  data  base  tor  tne 
presence  of  certain  states  tnat  satisfy  members  of  a set  of 
alerter  predicates. 

t'or  a given  data  case  transaction,  the  alerters  first  try 
to  determine,  witnout  referencing  the  contents  cf  tne  oata  case, 
it  it  is  a readily  ignorabie  update,  RIU.  This  is  determined  by 
comparing  tne  difference  vector  generated  oy  tne  transaction 
with  the  relevance  vectors  of  the  affected  case  relations. 
These  relevance  vectors  define  tne  set  cf  potentially  relevant 
updates.  A relevance  vector  is  assigned  to  each  relation,  base 
cr  virtual,  in  tne  construction  diagram  of  tne  alerters;  tnev 
are  used  to  control  tne  construction  ano  evaluation  ot  the 
target  relations  associated  to  the  aiertets. 


It  an  update  is  not  a KIU,  then  tne  relations  associateu  to 
tne  alerters  that  can  possibly  be  affected  have  to  be 
constructed,  in  oroer  to  evaluate  now  tney  weLe  modified  ana, 
eventually,  now  does  it  atrect  the  alerter. 

bsing  tne  relevance  vectors  defined  ter  each  relation,  it 
is  sometimes  possible  to  oetect  that  a transaction  will  not 
trigger  an  aierter  even  before  tne  target  has  been  completely 
constructed,  since  after  its  construction  diaoram  has  been 
partially  evaluated  we  may  determine  that  tne  modifications 
suffered  by  the  virtual  relations  evaluated  to  this  point  are 
irrelevant  to  tne  existing  alerters.  *nile  partial  evaluation 
is  oemg  performed,  tne  relevance  vectors  are  used  to  detect  the 
addition  or  deletion  of  tuples  according  to  the  alerters 
definition.  The  rules  for  tne  computation  of  these  relevance 
vectors  were  presented,  tegetner  witn  the  general  design  ct  the 
algorithms  that  apply  them. 

An  extended  relational  algeora  was  useo  tc  express  the 
alerter  definitions.  In  audition  tc  the  relational'  algebra 
operations  defined  in  [GOOD  /u ] , some  arithmetical  and  aggrenate 
capabilities  were  implemented  ir.  order  to  obtain  a much  more 
powerful  means  of  expression  tor  our  alerter  predicates,  ana , 
more  important,  to  study  the  way  in  wnich  tney  can  oe  treated  in 
the  context  of  alerters  in  relational  env ire  aments . 


Simple  and  Complex  alerters  are  definable  using  terms  of 
this  extenoeo  algeora. 


Using  tne  following  relations: 

LMP  : (emp# ,uept# , salary)  ano 

uEPT:.  ( dept # , mans  ) 

some  examples  of  complex  alerters  and  of  the  expressions  of 
tneir  predicates  are  given  Delow. 


1.  Structural  alerters:  '“Report  any  employee  whc  earns  mere 

than  his  manager". 

target=jcin((emp#) , (man# ) , 

EM  P f 

join ( (aept# ) , (aept# ) , 

EM  P , 

DL  PT ) ) ; 

2.  Statistical  alerters:  "Report  when  the  avetage  salary  of  a 

department  is  over  $15o0o". 

target=select (( average  > lbuud), 

bkawtot (( salary , cy  aeptO, 

EMr)  ) ; 

3.  Transition  alerters:  "Report  when  the  salary  oi  an  employee 

is  increased  by  more  than  2U£". 

target*select ( ( sal ar y . new  > salary. ola+20%) , 
changes ( (emp* ) , (enp* ) , 

EM  P . new  , 

EiM  r . 0 1 d ) ) ; 


hammer  ano  Sarin,  working  in  tne  closely  related  nelo  oi 
monitoring  integrity  assertions  [tmrnM  77],  ano  cased  on  tne 
premise  that  ciata  case  updates  can  generally  ee  anticipated, 
introduce  an  algontnm,  the  "assertion  processor",  wnicn 


— 
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generates  procedures  for  the  monitoring  of  cats  case  integrity 


assertions.  This  algorithm,  for  a given  assertion  and 


operation,  performs  an  analysis  to  determine  how  tne  expressions 


in  the  assertion  can  be  affected.  based  on  the  result  of  the 


analysis,  a set  of  "candidate  tests"  is  produced,  which  may  be 


used  to  monitor  for  assertion  violations  after  a transaction 


cost  estimator  hac  selected  the  least  expensive  test. 


We  feel'  that  there  are  several  aspects  wnich,  after  some 


research  effort,  could  further  improve  the  efficiency  of  tne 


techniques  we  uoscrioed  nere.  Construction  oiaorams  are  uefineo 


by  the  user  in  terms  of  his  view  of  the  expression  ct  the 


alerter  predicate.  This  does  not  mean  that  a taraet  relation 


can  only  be  expresseo  in  one  way,  since,  accordina  to  certain 


rules  which  can  easily  oe  ueriveu,  some  operations  in  an 


aiceoraic  exoression  couiu  oe  permuted  witn  no  efrect  cn  tne 


result,  based  on  tne  actual  contents  of  the  data  case,  the 


operation  involved,  ana  tne  freouency  of  the  same  type  of 


transactions , tne  construction  of  a taraet  relation  could  be 


sensioiy  more  erncient  it  tne  target  was  expressed  in  an 


specific  w3y.  As  an  example  consider  a target  relation 


reflecting  the  join  of  a elrtTriPLrtCt:  relation  with  a PLK3UN 


relation,  restricting  tne  resuit  to  those  persons  ever  ninety- 


years  ola,  aorn  in  ><ew  ioitk;  tms  cculo  be  eitr.ee  expressed  as: 


target  = seiect((age  > , 

select  ( (itl'ers)  , 
]omuon  lb)  , 

3 Ik!  n t LAe  t. , 
PE KoC.i ) ) ) ; 
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oc  as 


target3 select((NYers)  , 
join  ((  or.  ID)  , 
BIRTHPLACE , 
sel ec t ( ( age  > 90 ) , 
PERSON) ) ) ; 


of  one  of  those 
An  appropriate  set  of 


It  is  clear  that  the  efficiency 
implementations  is  significantly  greater, 
rules,  involving  all  or  some  of  the  factor?  mentioned  above, 
could  be  derived  to  guide  and  improve  the  definition  of  the 
construction  diagram. 

Another  aspect  that  could  improve  tne  efficiency  of  tne 
alerter  evaluation  is  related  to  the  representation  of  tne  data 
case  changes,  i.e.,  an  extension  of  the  definition  of  the 
difference  vector,  and  consequently  an  extension  of  the 
definition  of  the  relevance  vector.  We  have  defined  these 
vectors  as  reflecting  cher.oes  to  tneir  associated  attributes, 
but  have  excluded  any  description  of  the  chances.  In  many 
cases,  mostly  involving  restriction  and  arithmetical  operations, 
additional  information  about  the  nature  of  the  changes  can  be 
useful  in  the  evaluation  of  the  alerter  predicate.  For  example, 
in  the  alerter  "report  any  checking  account  whose  balance  falls 
under  $100",  we  should  ignore  any  deposit  made  to  the  account, 
since  even  though  the  oalance  is  mcaitlea,  it  can  only  increase, 
ana  therefore  the  transaction  should  oe  recoonizeo  as  irrelevant 
to  tnis  alerter,  and  possibly,  even  treated  as  RId's. 


L 
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A set  of  rules  for  tne  construction  and  use  of  these 
vectors  couia  be  formalized  in  a similar  manner  to  that  cf 
Cnapter  4,  ana  should  consiaerably  reouce  the  number  of 
occasions  in  wnich  partial  evaluation  nad  to  be  performed. 

Tne  purpose  of  this  ihesis  was  not  tc  design  programs  which 
efficiently  nanaled  relational  uata  oases,  but  rather  to  explore 
different  alerter  techniques.  In  our  case,  tne  relations 
hanaled  by  tne  programs  tnat  were  implemented  were  processed  in 
core,  naroiy  tne  expecteo  case  of  an  actual  implementation, 
rartial.  evaluation  is  the  most  sensible  ascect  witn  resoect  to 
tms  fact,  since  tne  efriciency  or  construction  oi  the  virtual 
relations  is  directly  related  tc  tne  actual  implementation  of 
the  relational  operators.  As  we  nave  said  before,  Rlu’s  con  be 
aetected  without  reference  to  the  oat a case  contents;  on  tne 
other  hand,  construction  diagrams  can  be  defined  ana  maintained 
with  an  expectedly  cooo  degree  of  independence  from  tne  actual 
stored  data  base,  tnererore,  the  etiiciency  of  tneir  operations, 
partial  evaluation  excluded,  should  not  vary  too  much  from  an 
implementation  to  anotnet . It  can  obviously  be  concluded  here 
that  in  the  same  measure  tnat  we  improve  our  capacity  of 
detection  cr  Rlu's,  (no  reference  to  tne  data  case  contents) , as 
much,  at  ieast,  alerters  woula  improve  its  efriciency  regardless 
ot  tne  environment  of  implementation . 


i 


« • 


Vve  feel  that  the  techniques  we  have  descrioed  should  allow 
efficient  monitoring  of  alerter  predicates  in  varied  relational 
implementations,  ana  while  they  have  Deen  expressed  in 
relational  algebra  terms,  tneir  use  in  aifterent  language 
frameworks  is  not  expected  to  pose  a very  difficult  problem,  as 
the  aaaptation  of  the  same  ideas  to  the  new  environment  should 
not  be  complicated. 
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APPENDIX  a 

Ain  IMPLEMEiNTATICiN  EXAMPLE 

As  an  illustration  of  the  alerter  tecnniques  we  nave 
described  in  this  Thesis,  we  shall  now  snow  the  results  of  a 
test  implementation. 

Our  goal  was  to  monitor  tne  use  of  the  DcC oYSTLM-10 
computer  at  the  Wharton  dcnool . To  this  effect  tne  files  3 YSTaT 
ana  RELAT'D  were  used  to  represent  the  following  relations: 


S YS TA T : ( J o 6 # , WaM E , LI.vE  , PROGRAM , ACC  #1 , ACC  #2  ) 

RELAT'D:.  (<JwMLA , WaME ) 

SYSiAT  was  being  dynamically  updated  to  reflect  tne  use  of 
tne  DEC-10  computer.  For  the  active  jobs,  it  contained  the 
following  information:  tne  joo  numoer ; user  name;  tne  line  to 
wnicn  it  was  attached;  the  program  tnat  was  being  run;  anc:  tne 
account  numoer  of  tne  user,  represented  by  two  account 


sub-numcer  s . 
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I The  tile  RELAT'D  contained  a set  of  owner-username  pairs, 

which  aefineo  a relationship  between  some  users  and  a set  of 
"owners".  (let  us  imagine  each  owner  as  a supervisor  ot  the 
activities  of  his  related  users.) 


VI 


O 


based  on  this  relations  the  following  alerters  were 
defined  : 

define  noae  L'D1  = 

pro  j ec  t ( (OWMPK , W/m'iE  , ACC#1 , aCC  2 ) , 
join(  (Jai-iE)  , (uAriE)  , 

SYS TAT , 

RELAID) ) ; 

end ; 


C 


‘l 


define 


ena ; 


alerter  AL1= 
monitor  for  additions, 

indicated  oy  JOB  if , ACC  #1 , ACC  if  2 , 
then  r epor t (■ star  ting  APL  program*); 
target= 

select ( ( PRuoRAN  =a  PL ) , 

SYS’IAT)  ; 


t 


define 


end ; 


aierter  AL2  = 
monitor  tor  aduitions, 

indicated  by  ACC  #1 , ACC $2 , 

tnen  report(‘acct  with  more  than  one  job*); 
target= 

select ( ( CO Du T > 1 ) , 

r count ( (ACC#1 , ACC  #2 ) , 

S YS  TAT ) ) ; 


define  alerter  AL3  = 

monitor  ior  additions, 

indicated  dv  CWhLK , ACC #1 , ACC #2 , 
then  report ( ‘ related  user  started  APL1); 
target= 

selectl ( PROGRAM *A PL ) , 

«&l)  ; 


end  ; 
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uefine  alerter  AL4  = 

monitor  for  aaaitions, 

indicated  by  all  attributes, 
then  report {' related  user  logged  in’); 
target= 

pro  j:ec  t ( (GtowEK , hAilB , ACC  #1 , ACC  »2  ) , 

WD1)  ; 

end ; 

For  iaenti f ication  purposes,  a message  was  associated  to  the 
"report"  action  of  each  alerter. 


The  StfSTAT  file  was  updated  by  periodically  copying  it  from 


the  general 

files 

of  the 

system , 

it 

was  done  based  on  an 

spec  if iabl e 

time 

basis,  expressed 

in 

terms 

of  seconds. 

Accord inaiy , 

the 

pred icates 

asscc ia  ted 

to  tne 

alerters  were 

evaluated  with  a similar  periodicity. 

We  snail  now  show  the  printout  resulting  from  the 
application  of  these  alerters  to  a normal  work  cay  at  WCC,  when 
tne  programs  were  active  for  approximately  fifteen  minutes. 

The  programs  will  initially  produce  a printed  image  of  tne 
alerter  definitions  tnat  were  created.  Then  they  wili  report 
the  tuples  satisfying  tne  alerter  predicates  when  they  were 
initially  set;  ana  finally  normal  triggering  of  the  alerter, 
aue  to  data  changes,  is  shown. 


(Tne  PGP-10  coae  of  the  programs  used  in  this  test 
implementation  will  oe  shown  in  Appendix  £.) 


> 


1) 


J 


[GiiCS'l'  TR/aNSAC  TIGN  LOG] 


LuGIn  3u56/z 

JuB  Su  Wharton  Scnooi  KL  6u3v20  TTY165 
[LGwJSP  Otner  joos  same  PPN: 25,37] 

1447  18-Oct-7b  Wed 

You  have  ola  NETMAIL  at  20:45  on  17-Uct-7b 


. r pop 

POPlu 
se  tpop 

: ucomp  aler  ter  ; 


- ALERTER#:  4 - RELEVANCE: [ 1 0 1 1 1 1] 

- (OWNER,  NAME,  ACCffl,  ACC #2)  - ACCOUNT  uF  RELATED  USER  LOGGED  IR 

1 <FUNCTIGN>PROJECT  -[[1267]] 

2 <FUnCTIGN>JGI^  - [[  2]  [2]] 

J <Bh>  - RELATED 

3 <3R>  - SYSTaT 

- ALERTER#:  3 - RELEVANCE:  [lOlOuOOli] 

- (OWNER , ACC  if  1/  ACC  #2)  - DELATED  USER  ST.vRTS  rtPL  PROGRAM 

1 <e unction >3 elect  - [[  5j  <fu^ction>nil] 

2 < FUNCTION >JOIi»  - [[  2]  [2]] 

3 <3k>  - RELATED 

3 <3 R>  - SYS TAT 

- ALERTER#:  2 - RELEVANCE: [ 1 u 1 1 0] 

- (ACCtfl,  ACC # 2 ) - ACCOUNTS  WITH  MORE  THAN  ONE  JOB 

1 <FUnCTIUN>S ELECT  - [[  1]  <FUNCTION>NIL ] 

2 < FUnC TIUN >RCOUNT  - [[  5 6]] 

3 <Bk>  - SYS TAT 

- ALERTER#:  1 - RELEVANCE:  [10100011] 

- (JOB#,  ACC  #1 , ACC  # 2 ) - STARTING  AN  APL  PROGRAM 

1 < FUNC  T ION  >5 ELECT  - [[  4]  < FUNCTION >N I E ] 

2 <3K>  - SYS TAT 

< BK>  - INDICATES  A BASE  RELATION 


ALERTER  # 1 TRIGGERED: 

(JOB#,  ACC # 1 , ACC # 2 ) - STARTING  AN  APL  PROGRAM 
4 3070  1013 

10  3000  1337 

12  3000  1341 


1 1 HI'.  II..JJJ- 


27  3075  1326 

28  3000  1170 

29  3360  1004 

31  3117  1100 

33  3060  3 

35  3117  1105 

38  3213  1005 

39  3213  1011 

40  3000  1156 

42  3075  1326 

' 46  3000  1123 

47  3000  1114 

48  4000  43 

ALERTER  # 2 TRIGGERED: 

(ACC#1,  ACC #2)  - ACCOUNTS  WITH  MORE  THAN  ONE  JOS 
2 3000 

2 3075 

2 4164 

3 3056 
11  1 

ALERTER  # 4 TRIGGERED: 

( OWNER , NAME,  ACC#1,  ACC#2)  - ACCOUNT  OF  RELATED  USER  LOGGED  IN 
3UNEMA  SERRA  3U56  2 

SUN EM A SYSTEM  1 2 

MORGAN  SYSTEM  1 2 

ALERTER  # 2 TRIGGERED: 

( ACC #1 , ACC #2 ) - ACCOUNTS  WITH  MORE  THAN  ONE  JOB 
12  1 

ALERTER  # 1 TRIGGERED: 

(JOB#,  AC  C # 1 , ACC  #2 ) - STARTING  AN  A PL  PROGRAM 
26  2627  1002 

ALERTER  # 1 TRIGGERED: 

(JOS#,  ACC #1 , ACC #2 ) - STARTING  AN  AFL  PROGRAM 

43  4000  43 

ALERTER  # 1 TRIGGERED: 

(JOB#,  ACC  #1 , ACC  #2 ) - STARTING  AN  APL  PROGRAM 
21  3000  1123 


ALERTER  * 4 TRIGGERED: 
(OWNER,  NAME,  ACC  #1 , ACC #2) 


ACCOUNT  wF  RELATED  USER  LOGGED  L.\- 
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BUNEMA  WE3EL  3000  1036 

ALERTER  # 2 TRIGGERED: 

( ACC #1 , ACC #2 ) - ACCOUNTS  WITH  MORE  THAN  ONE  JOB 
13  1 

ALERTER  # 1 TRIGGERED: 

(JOB#,  ACC #1 , ACC # 2 ) - STARTING  AN  APL  PROGRAM 
17  3000  1036 

15  3000  1017 

ALERTER  # 2 TRIGGERED: 

( ACC #1 , ACC #2 ) - ACCOUNTS  WITH  MORE  THAN  ONE  JOB 
12  1 


I 


1 


ALERTER  # 3 TRIGGERED:. 

(OWNER,  ACC#1 , ACC # 2 ) - RELATED  USER  STARTS  APL  PROGRAM 
BUNEMA  3000  1036 


ALERTER  # 1 TRIGGERED:. 

(JOB#,  ACC #1 , ACC # 2 ) - STARTING  AN  APL  PROGRAM 
53  3000  1427 

39  3213  1011 


I 


APPENDIX  S 
CONTROL  programs 
- POP-10  CODE  - 

We  shall  now  show  the  actual  code  of  the  control  programs 
that  were  used  to  implement  the  previous  example.  The  proarans 
are  all  written  as  PGF-10  functions,  and  are  grouped  together, 
with  a not  too  tight  criteria,  according  to  their  use. 

The  function  TRANS EVAL , described  before,  is  the  starting 
point  for  the  evaluation  of  the  alerters.  After  the  SYSTAT  and 
RELATD  files  are  modified,  this  function  is  referenced  using  a 
list  that  contains  the  construction  diagram  nodes  associated  to 
the  base  relations.  Each  node  contains  an  image  of  botn 
previous  and  actual  states,  from  which  the  modifications 
suffered  by  the  relations  can  be  evaluated.  That  would  be 
sufficient,  as  all  ether  functions  would  be  referenced,  as 
necessary,  from  this  starting  point. 


3 
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COMMENT  ALERTERS: 

ALERTER  EVALUATION  FUNCTIONS  - SERRA  9/7S 


FUNCTION  TRANSEVAL  B3ELST ; 

VARS  F LG  XI; 

(TIME]  . POPME3S->FLG; 
3SELST-XX1 ; 

LOO FI F NOT (3SELST. NULL)  THEN 
ALERTEVAL (BSELST. HD, FLO) ; 
3SELST. TL->3SELST; 

CLOSE; 

LOO P I F NOT (XI. NULL)  THEN 
XI . HD.  NEWF->Xl . HD.  OLDR  ; 
Xl.TL->Xl; 

CLOSE; 

END; 


FUNCTION  ALERTEVAL  NODE  FLG; 

VARS  XI; 

BOTHEVAL (NODE , FLG) ->CTNT  (NOGS) ; 

IF  NOT (FLAG1 (NODE) =FLG)  AND  CHANGED (NODE . CTNT , NODE . RLVNCE ) 
THEN 

IF  NOT (ALRTSW (NODE) =0) 

THEN 

TRIGGER (NODE) ; 

ELSE 

NODE  . POST- > XI ; 

LOO PI F NOT  (XI. NULL)  THEN 

IF  CHANGED (NODE . CTNT , XI . HD.RLV) 

THEN 

ALERTEVAL (XI. HD. PST, FLG) ; 

CLOSE; 

XI.TL->XI; 

CLOSE; 

CLOSE  ; 

FLG->FLAGl (NODE) ; 

CLOSE ; 

END; 


FUNCTION  BOTHEVAL  NODE  FLG; 

CONS (EVALOLD (NODE, FLG) , CONS (GVALNSW ( NODE , FLG ) ,NIL)) ; 


END; 


FUNCTION  EVALNEW  NODE  FLG ; 

VARS  XI  X 2 ; 

IF  NODE . OPRN . RTOR=3ASE  OR  F LG*FLAG3  (NODE ) 
THEN 

NEWR  (NODE ) ; 

ELSE 

F LG - > F LA  G 3 (NODE ) ; 

E VA  LNEW ( NO  DS . PRE . HD , F LG ) ; 

IF  NOT (MULL (NODE. PRE. TL) ) 

THEN 

IF  NODE. OPRN. RTOR=CHANGSS 
THEN 

EVALOLD (NODE. PRE.TL. HD, FLG) ; 

ELS  E ; 

E VA  LN  E W ( NO  DE  . PR  E . TL . H D , F LG ) ; 
CLOSE ; 

CLOSE; 

NODE. OPRN. RAND->Xl ; 

LOOPIF  NOT (NULL (XI) ) THEN 
XI. HD; 

XI . TL->Xl ; 

CLOS  E ; 

. (NODE. OPRN. RTOR) ; 

C LOS  E ; 


FUNCTION  EVALOLD  NODE  FLG; 

VARS  XI  X2; 

IF  NODE. OPRN. RTOR=3ASE  OR  FLG*FLAG2 (NODS ) 
THEN 

OLDR (NODE) ; 

ELSE 

F LG - > F LA  G 2 (NODE) ; 

EVALOLD (NODE. PRE. HD, FLG) ; 

IF  NOT (NULL (NODE. PRE.TL) ) 

THEN 

EVALOLD (NODE. PRE.TL. HD, FLG)  ; 

C LO  S E ; 

NODE. OPRN. RAND->XI; 

LOOPIF  NOT  (NULL  (XI) ) THEN 
XI. HD; 

Xl.TL->Xi; 

CLOSE; 

. ( NODE . OPRN . R TOR ) ; 

l LOo c ; 

CND ; 


i 


i> 


FUNCTION  CHANGED  MCTNT  NRLVC ; 

VARS  XI; 

FAL3E->Xl ; 

IF  NRLVC. TL. HD 
IHEN 

DIFRNCE ( PROJEC T (NCTMT . HD , ONLI3T (NRLVC . TL . TL , 1 ) ) , 

PRO JEC I ( NC TNT . TL . HD , ON L I S T ( hr L VC . TL . TL , 1 ) ) 

) .RL. NULL. WOT  OR  XI  ->  Xl; 

CLOSE ; 

Ir'  NRLVC.  HL 
THEN 

DIFRNCE (PROJECT (NC TNT . TL . HD , ONLIST (NRLVC . TL. TL , i ) ) , 
PROJECT  (NC'lNl  . tlD , OinLIST  (NRLVC  . TL . TL , 1 ) ) 

) .RL. MULL. NOT  OR  Xl  ->  Xl; 

CLuSl.  ; 

Xl; 

END ; 


function  trigger  ;.<ode; 

IF  DATAWORO  (MSG  (NODE  ) )=,‘CJTRIP“ 

THEN 

2 . NL ; 

' ALERTER  y . PR3TR  I^G ; NO  DC  . A LR  IS  W . PR' ; 
' TRIGGERED;  (J  .PkSTRInG; 

1 . NL ; 

PR3TRING (MSG (NODE) ) ; 

1 . NL ; 

PRRELA  (DIFFER  (NODE  . CTNT  , NODE  . RLVUCE ) 
ELSE 

(NODS. MSG)  (ivJDS)  ; 

C LOS  E ; 

END ; 


FUNCTION  DIFFER  MCTNT  NRLVC; 

IF  NRLVC. TL. hD 
THEM 

DIFRNCE (PROJECT (NCTMT . HD , ONLIST (NRLVC . TL . TL , 1 ) ) , 

PROJECT (NC  TNT . TL. HD , ONLIST (NRLVC . TL. TL , 1 ) ) ) ; 

CLOSE ; 

IF.  NRLVC.  HD 
THEN 

DIFRNCE (PROJECT (NCTMT . TL . HD , ONLIST (NRL VC . TL . TL , 1 ) ) , 
PROJECT  (WCTNT . HD, ONLIST  (kRLVC  . TL.  TL  , 1 ) ) ) ; 

CLOSE ; 

END ; 
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COMMENT  ALERTERS: 

CONSTRUCT  ION  DlrtGRArl  Pii\NDLInG  FUhCTIONS  - SERRa  y/78 


VAiiS  EASE  PSI  KLv ; 

' daSE  K£LATIOilti->flASt ; 

RECORDPNS  ( 1 COWS-DI  AGitAi'l-NOOE  ,GEwL3rO  ( 1 u ) ) ; 
— >DiFRN  ->MSG  ->c'L«(j 
->FEQVL  ->RLVimCL  ->CTNT 
->GPRn  ->PRE  ->P03T 
— >ALRTSto  — >CDD£ST  — >CDCO^o; 


E UnCTION  CGN3C NOG  RfViOR  PAR  ERAND; 

VARS  X L ; 

(NIL, NIL, NIL, NIL,  [%wIL,NIL*]  , 

NIL , NIL , [%;mIL,NIL,NIL%]  , NIL,  NIL)  . CDCGuS  - >X ; 

0->ALRlSW (a) ; PAk->PRE(X); 

CONS  (RATCR  , CONS  ( LRAND  , iil  L ) ) - >uPRn  (X  ) ; 

RLVUPD (A , POST (PAR. HD ) ,G£nLST0  (LENGTH  ( PAR.  HD.  CLDR.  DP.  KS  ) +2  ) ) 
~>POST (PAR. HD)  ; 

PAR . HD. OLuR . DP : : n I L ; 

IP  NOT (PAR. TL. NULL ) 

THEN 

PAR. TL. hD.OLDR. DP: :NlL; 

kLvuPD  (A  , PgST  (PAR.  TL.  HD)  ,GCLiLS'i  U (LEnGTIi 

(PAR. TL. HD.OLDR. DP . RS ) +2 ) ) — >POST (PAR. T L . HD)  ; 

C LO  S E ; 

ERAND— >L ; 

LoOPIr'  NOT  (L . NULL  ) THEN 
L.HD;  L.TL->L; 

CLOSE  ; 

. RATOR->OLDR (X) ; OLDR ( A ) - > N s W R (X) ; 

GEwLSTO (LENGTH (OLDR (A ) . DP. RS ) +2 ) ->RLVNCE ( a ) ; 

PEQVLNCE (RATOR , PAR , ERAND ) ->f EQVL (A ) ; 

X; 


FUNCTION  DEP3ASE  KELL; 

VARS  X; 

(NIL, NIL, NIL, NIL, [%NIL,NIL%] , 

NIL, NIL, [%N IL, NIL , NIL% ] , NIL, NIL) .CDCONS->X; 
IP  RELL.NULL 
THEN 
NIL; 

ELSE 

0->ALKTSW(X)  ; 


COWS  (RELL.  HD.  DF,  NIL)  ->OLDR  (X)  ; 

CONS ( SaSE , (NIL: : NIL) ) ->OPRN  (a ) ; 

CONS  (X  , DEFSASE  (RELL . TL ) ) ; 

OENL3TU (LENGTH (OLDR (X) . DF . RS) +2 ) ->RLVNCE (X) ; 
CLOSE; 

END ; 


FUNCTION  RLVCOMP  NODE  RLVL  ANCS  ALNO; 

VARS  LI  X; 

IF  ANCS  =N I L 
THEN 

ALNO->ALATSW (NODE ) ; 

ELSE 

RLVUPO  (ANCS,  NODE  . POST , RLVL ) - >NOD£  . POST; 

C LOS  E ; 

LOR  (RLVL  , RL7NCE  (NODE  ) ) ->RLVNCt  (hODE  ) ; 

PRE (NODE )->Ll;l->X; 

LOO  PI F NOT (LI. NULL)  THEN 

RLVCOMP (LI . HD, RULES (NODE . OPRN , RLVL , ELM NT (X , NODE . FEQVL ) 
GEaLSTC ( LENGTH ( L 1 . HD . OLDR . LF . RS ) ) , X ) , NODE , 0 ) ; 

LI . TL->L 1 ; 1+X->X; 

C LuS £ ; 

END ; 


FUNCTION  FEQVLNCE  RATOR  PRED  RANDS; 

VARS  L LI  L2; 

0->Ll; 0->L2; 

LENGTH (PRED. HD. OLDR. DF . RS ) - >L 1 ; 3ENLST0 (LI) - >L ; 

IF  NOT (PRED. TL. NULL)  THEN 

LENGTH (PRED. TL. HD. OLDR. DF. RS) ->L2; CLOSE ; 

IF  LM EMBER (RATOR , ( % UN  ION , INTR3CT, DI FRNCE  % ] ) THEN 

COMPLMNT (NIL, LI, 1) : : (COMPLMNT (NIL, L2, 1) : :NIL) ;EXIT; 

IF  LMEMBER  (RATOR,  (* SELECT , MAXTUPL  , MI.VTUPL %)  ) THtN 
COMPLMNT (NIL, LI, 1) : ;NIL;£XIT; 

IF  RATOR =PRGJEC  T THEN 
[ * RANDS . HD% ] ; EXI T ; 

IF  LMEMBER (RATOR, [%JOIN, CHANGES %) ) THEN 
COMPLMNT (NIL, LI, 1) : : 

(LOCOMPLMNT  (RANDS.  TL.  HD,  L2,l)  : :NIL)  ;EXIT; 

IF  RaTOR *XCPROD  THEN 

COMPLMNT  (NIL,  LI,  1)  : : (LOCOMPLMNT  (NIL,  L2, 1)  : :nIL)  ; EXIT  ; 
IF  RATOR =DI VIDE  THEN 

C OM  PL  .'I  NT  ( Ra  N DS  . H D , L 1 , 1 ) : : (NIL:  :NIL)  ;EXIT; 

IF  RATOR =A VERAGE  THEN 
NIL; EXIT ; 

IF  RA TOR *B KO W TOT  THEN 


r 


(% RANDS. HD. TL%] ;EXir ; 
Ir  KATOR^Kv, DUiVi'  THEN 

[ « 0 : J Ra NDS . HU%  ] ; £ X I x ; 


END; 


FUNCTION  RL\/UrO  ANCS  LPOo  *oVL; 

IF  LPOS.NuLL 

THEN  ,T  r \ 

CONS (ANCS: ; RLVL , NIL) ; 

ELSEIt’  ANCS=LPOS . HD. PST 

"“CM!  (COHS  (l»S  • W. • W»  <“•«•  ’ “<» ' “ ■ *LV  ’ ’ ’ ^ ’ ’ 

LPOS . HD : : (RLVUPD (ANCS  r EPOS . TL , RLVL ) ) 

CLOSE; 

END ; 

function  RULES  OPT  RLVN  e-£Q  ^V2  X; 

XI  X 2 X 3 RULE  ORTR  ORNL; 

IF  OPT. TL. NULL 

THEN 

NIL->ORND; 

tLSSLrfHi<*.0*T.TL.HO)->OiiHD! 

SSf  »0->0*Ii»  IA4SOCB  (ORTH,*)  ->»Ut6 1 
IF  NOT  (RULE  . TL.  riO-U  ) 

THEN  . , 

Ic*  R u L £ • r L • H Lf ■“  1 

inC CON PLM NT (NIL, LENGTH (RLV2)  ,1)->X1; 

ELSE 

ORND->Xl; 

LOO PI E NOT  (Xl. NULL)  THtN 

l->£Lrti«(Xl.HD,RLV2)  ;a1.  iL->Xi, 

CLOSE ; 

CLoSE ; 

X F X ( RU Lis*  • T L • SO • 1 ) 

rhC*P£si->Xl;R0LE.TL.TL.HD->X2;  ^->a3; 

LoOPlr  NvT(Xi.NULL)  THEN 
1 •♦•X  3->X3 ; 

X F fiJO ^ • HD-u  ) 

iOLI-'  (a2  rvuD  CLNNx  (a  3 , RLvN  ) ) oR 


« 


1" 


l 


(X2. NOT  AND  ELMNT (X3 , RLVN ) AND 
LM EMBER (Xl . HD,0*ND) ) 

THEN 

1->ELMNT (Xl . HD, RLV2) ; 

^ LO  b I / 

CLOSE ; 

Xl . TL->X1 ; 

CLOSE; 

CLOSE ; 

(RULE  . HD)  (RLVN.HD:  ; (RLVN.TL.HD:  : NIL)  ) ORLV2; 

END; 


FUNCTION  TAB  SRC H ORTR  X; 

VARS  TABLE; 

[% 

[%BKDWTOT, [% [%LORl  ,2,0%]%]  %], 

[ %RCOUNT  , [ % [ %LORl  ,2,0%]%]  %], 

[ % INTRSCT , [% [%LAND1, 1, 0%]  , [ % LAND 1 ,1,0%]%]%]  , 
[ %UN  ION  , (%  [%LAND1, 0,  i%]  , [ %LAi\Ll , 0,1%]%  ] % ] , 
[ %LI  FR.«CE  , [ % [%LAND1 ,1,0%]  , [ %LN01  ,1,0%]%]%]  , 
[ %S£L£CT  , [ % [ % LAN  D 1 , 2 , 1 % ] % ] *], 

[ % DI VI DE  , [ % [ % LAN  D 1 , 1 , 0 % ] , [ % LNOT  ,1,0%]%]%], 
[% PROJECT, [% [%LAND1, 2,0%]%]  %] , 

[ % JO  IN  , [%  [%LANDl ,2,1%]  , [%LAND1, 2, II] % ] % ] , 
[%AVERAGE,  [%  [%LORl  ,2,0%]%]  %}, 

[ %MAXTUPL , [%  [ % LAND1 , 2,0%]%]  %]  , 

[ %M  IL'ITUPL  , {%  [%LAND1 , 2,0%]%]  %]  , 

[iChANGES  , [%  1%LAND1, 1, 0%]  , [%Lb,Rl  ,1,0%]%]%]  , 
[ $ AC  PROD  , [%  [%LAi'.Dl  ,0,1%]  , [ s L AN  D 1 , O , j.%]  -6  J -s  j 
% ] ~> TABLE ; 

L^UPIF  NOT (TnBLE. NULL)  THEN 
IF  X = 3 
THEN 

1. NL; TABLE. HD. PR; 

ELSE IF  TABLE. HD. HD-OATR 
THEN 

ELM NT (X , TABLE . HD . TL. HD ) ; EXI T ; 

TABLE  . TL->TABL£  ; 

CLOSE; 

NIL; 

END ; 
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FUNCTION  OLDR  X; 

X.CTNT.HD; 


END; 
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COMMENT  RELATIONAL  ALGE3RA  OPERATIONS : 

RELATIONAL  OPERATORS  - 3ERRA  9/7o 


FUNCTION  UNION  Rl  R2; 

RECSORT (Rl,NIL)->Rl; 

RECSORT (R2 , NIL ) ->R2; 

CONS (R2. DF, UN  ION 1 (Rl . RL , R2. RL , Rl . DP . FN , R2 . DF . FN ) < >R2 . RL ) ; 

END; 


FUNCTION  UN  ION  1 LR1  LR  2 LRHFl  LRHF2; 

VARS  LR3 ; 

NIL->LR3; 

IF  LR 2 . NULL 
THEN 
LR  1 ; 

ELSE 

LOO PI F NOT  (LRl. NULL)  THEN 

IF  NOT  (Ril EMBERS  (LRl . HD,  LR2 , LRHFl . TL . TL,  LRHF 2 . TL.  TL)  ) 
THEN 

CONS (LKl. HD, LR3) ->LR3; 

CLOSE ; 

LKl . TL->LR 1 ; 

C LOSE ; 

LR  3 ; 

CLOS  E ; 

END ; 


FUNCTION  INTRSCT  Rl  R2; 

RECSORT (Rl, MIL) ->Rl; 

RECSORT (R2, NIL) ->R2; 

CONS  (Rl. DF, IN TRSCTl (R 1 . RL , R2 . RL , Rl . DF . FN . TL . TL , R2 . OF.FN.TL. TL)  ) ; 

END; 


FUuCTION  IlmTRSCTI  LKl  LR 2 LRHFl  LRHF 2 ; 

VARS  LK3; 

NIL->LR3; 

LOO PI F NOT (LR1. NULL)  THEN 

IF  kM EM3ERS ( LR 1 . HD , LR2 , LRHF 1 , LRHF 2 ) 
THEN 

COnS ( LK 1 . HD , Lk  3 ) ->LR  3 ; 

CLOSE  ; 

LKl. TL->LRl; 

CLOS E ; 


« 
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FUNCTION  DIFRNCE  Rl  R2; 

KLCSOKT (Rl,NIL)->Rl; 

RFC  SORT  (R2,NTL) ->R2; 

CONS  (kl. DF,DIFknCE1  (Rl. RL, R2. RL, Rl . Dt . FN . TL . 'i'L , R2 . Dt  . FN.TL.TL)  ) ; 

END; 


FUNCTION  DIFRNCEl  LRI  LR2  LRHFl  LKHF2; 

VrtRS  LR3; 

NIL->LR3; 

IF  LR2. NULL 
THEN 
LRi; 

ELSE 

LOO PI F NOT (LRI. NULL)  THEN 

IF  NOT  (RflENBERS  (LRi. HD, LR2,  LRtlFl , LRHF2) 
THEN 

CONS (LRI. HD, LR3) ->LR3; 

C Loi>  E ; 

LRl.TL->LRl; 

C LuS E ; 

LR  3 ; 
o L0«3  L ; 

END ; 


FUNCTION  PROJECT  R RSSLCT; 

VARS  RSCDEF; 

RLCSORT (R, RSSLCT) ->R; 

DEFREC1 (R. DF.Nrf, LS ELECT (R. OF . RS , RSSLCT) ) ->RLCDEP ; 
CONS  (RLCDE’F,  PROJCCT1  (R.  RL,  LSELECT 

( R . DF . FN . TL . TL , RSSLCT ) , REC  DE  F . FN ) ) ; 

END; 


FUNCTION  PROJECT1  LR  LRtlFl  LKriF 2 ; 
VARS  LRHF 3 Rl  R2  LR 3 ; 

N I L->LR3 ; 

LOO PI F NOT (LR. NULL)  THEN 
LRHF 1->LRHF  3 ; 

LOO PI F NOT (LRHF 3. NULL)  THEN 
(LRHF3. HD) (LR. HD) ; 

LRHF  3 . TL->LRHF  3 ; 

CLOS  £ ; 
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FUNCTION  XCPROD2  Rl  LR2  DEST1  DE3T2  CONS 3; 
VARS  LR3; 

NIL->LR3 ; 

LOOPIF  NOT  (LR2.  NULL)  THEN 
DESTl (Rl) ; 

DEST2 (LR2. HD) ; 

CONS (CONS  3 ( ) ,LR3)->LR3; 

LR2. TL->LR2; 

CLOSE ; 

LR3; 


END; 


FUNCTION  JOIN  Rl  R2  FNSLCTl  FNSLCT2; 

VARS  FNSLCT3  RECDEF ; 

RECSORT (Rl, FNSLCTl) — >Rl; 

RECSORT (R2 , FNSLCT2 ) ->R2; 

COMPLIANT  (FN3LCT2,  LENGTH  (R2.  DF.  RS)  , 1 ) ->FN3LCT3; 
DEFREC1 (Rl. DF. NM<=>R2. DF.  NM , Rl . DF.  RS 

<>  L3 ELECT (R2. DF. RS, FNSLCT3) ) ->RECDEF ; 
CONS (RECDEF, JOIN1 (Rl . RL , R2 . RL , 

LS ELECT (Rl. DP. FN.TL. TL, FNSLCTl)  , 

LSELECT (R2. DF. FN.TL. TL, FNSLCT2) , 

Rl.  DF. FN. TL. HD, 

LSELECT (R2. DF. FN.TL. TL,FNSLCT3) , 

RECDEF. FN. HD) ) ; 

END; 


FUNCTION  JO INI  LR1  LR2  JRHF1  JRHF2  DESTl  D23T2  CON33; 

VARS  LR3; 

NIL->LR3; 

LOO PI F NOT  (LR1. NULL  OR  LR2. NULL ) THEN 
LOO PI F NOT  (LR 2. NULL)  AND 

GTRECCRD  (L Rl. HD, LR2. HD, JRHFl , JRHF2)  THEN 
L R2.TL->LR2; 

CLOSE; 

JOIN  2 (LR1 . HD , LR2 , JRHF 1 , JRHF  2 , DE3T1 , DE3T2 , CONS  3 ) <>LR3->LR  3; 
LR 1 . TL->LR 1 ; 

CLOSE; 

LR  3 ; 

END; 


FUNCTION  JO IN 2 Rl  LR 2 JRHF 1 JRHF 2 DESTl  DEST2  CON33; 

VARS  L LR3; 

NIL->LR3; 

LOOPIF  NOT (LR2. NULL)  AND  NOT (GTRCCORD (LR2 . HD , Rl , JRHF 2 , JRHF 1 ) ) THEN 
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IF  EQRCCND (Rl , LR2 . HD , JRHF 1 , JRHF2) 
THEN 

OESTl (Rl) ; 

DEST2->L; 

LuOPIF  NOT (L. NULL)  THEN 
(L. HD) (LR2.HD) ; 

L . TL->L ; 

CLuSE ; 

CONS (CONS  3 ( ) , Lk3 ) ->LR3 ; 

CLOSE ; 

LK2 . TL->LR2; 

C LoSE ; 

LR3; 

END; 


FUNCTION  DIVIDE  Rl  R2  LSLCTl  LSLCT2; 

VARS  LSLCT3; 

COMPLMNT (LSLCTl, LENGTH (Rl. DF.RS) ,1)->LSLCT3; 

RECSORT (Rl , LSLCT3 ) ->Rl; 

ReCSORI ( R 2, LSLCT2) ->R2; 

PROJECT  (CONS  (Rl. DF, DIVIDE  1 (Rl . RL, R2. RL, LS ELECT (Rl. Dt  . r'«.TL.TL, 
LSLCTl ) , LS  ELECT  (R2 . Dt  . r'N . TL . TL , LS  LCT2 ) , LS  ELECT 
( Rl . DF . PN . TL . TL , LS  LCT 3 ) ) ) , LS  LCT3 ) ; 

EnD  ; 


FUNCTION  DI.V1DE1  LR1  Lk2  LRHFl  LKht'2  DLST1; 

VARS  KA  L rt; 

IF  LRl.NoLL 
THEN 
NIL; 

ELS  E 

LRl. HD->RX; 

NTL->L;  LR2->M; 

LOO PI F NOT (LRl. NULL)  AND 

EQRCCND  (RX,  LRl . HD,  DLSTl , QEST1 ) THE i'< 
CONS (LRl. HD, L)->L; 

LR1.TL->LR1; 

CLOSE ; 

ALLSORT (L , LERECORD ( % LkHFI, LRHFl  %))->L; 
LOO P I F NOT  (M.  NULL)  THEN 

IF  NOT  (Ri-i EMBERS  (M.  HD,  L,  LRHF2,  LKiir’l)  ) 

then 

DI vIDEl (LRl , LR2 , LRHFl , LRHc  2 , DEST 1 ) ; 
EXIT  ; 

M.TL->M; 
v-  Lo  S E ; 


COWS  (RX,DIVIDEl(Lkl,LR2,LRhFl,LRhF.2,DLSTl)  ) ; 
CLOSE; 

EwB ; 


FUNCTION  AVERAGE  R FNSLCT; 

VARS  L RECDEF; 

DEFRECl  (R.  DF.  NM<  = > '-AVRGE^  , [0  V U ] ) ->RECDEt  ; 
AVERAGE  1 (R.  RL , LS ELECT  (R.  Dr’..  FN.  TL.  TL,  F NSLCT)  ) ->L; 
IF  L . TL . HL=0 
THEN 

(-1 ) ->L . TL. HD; 

CLOSE ; 

CONS  (RECDEr  , CONS  ( (RECDEF. FN. HD) 

( ( L . HD ) / ( L . TL. HD ) , L. HD , L . TL . HE ) ,NIL) ) ; 

END; 


FUNCTION  A VERAGE 1 LR  LRHF ; 

VARS  L; 

COl'IS  (U  ,CONS  ( U , NIL)  ) ->L  ; 

LOO PI F NOT (LR. NULL)  THEN 

(LRHF. HD) (LR. HD)+L. HD->L. HD; 
1+L.TL. HD->L.TL. HD; 
LR.TL->LR; 

CLOSE ; 

L; 


FUNCTION  MAXTUPL  R LSLCT; 

VARS  L; 

IF  LSLCT. NULL 
THEN 

R. DF . F N . TL . TL - > L ; 

ELSE 

LS ELECT (R. DF. FN. TL. TL, LSLCT) ->L ; 
CLOS  E ; 

CONS (R. DF, NAXTUPL1 (R. RL, L) ) ; 

END; 


FUNCTION  NAXTUPL1  LR  LRHF; 
VARS  L; 

IF  LR . NULL 
THEN 


NIL ; EXIT; 
LR. HD; : NIL->L  ; 
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FUNCTION  BKOMTOTl  RL  LRHFl  LRHF2  LRnF3; 

VARS  XU  XI  X2  LRHF4  CUT  TOT; 

RL->XU ; N'IL->X2; 

LuOPlF  NOT  (XU.  NULL)  THEN 

1->CNT; (LRHF2.HD) (XU . HO ) -> TOT ; 

XU. TL->Xl; 

LOO  PI  F NOT  (XI.  NULL)  AND  EORCCND  (xU  . HD , Xl . HD , LKHi;' 1 , LRUF 1 ) THEN 
I+CNT->CNT ; 

(LKhF2. HD) (xl . HD)+TOT->TOT ; 

X1.TL->XI; 

CLOSE  ; 

LRHFl ->LRHF  4 ; 

LoOPIF  NOT (LRHF4 . NULL ) THEN 
(LRHF4.HD) (XU.HL) ; 

LRHr'4 . TL->LRHF  4; 

CLOSt ; 

CNT ; TOT ; 

CONS ( (LRHF3.HD) () ,X2)->X2; 

Xi->XU; 

C LOSE ; 

X2 ; 

END ; 


FUNCTION  RCOuNT  k RoSLCT; 

VARS  RECDEF; 

IF  RS5LCT.HD=U 
THEN 

NIL->RS5LCT; 

CLOSE ; 

RECSORT (R, R3SLCT) ->R ; 

DEFREC1 (R. DF.NM<=> 'CMTi ,0: : L3ELECT (R. DF. RS , RSSLCT) ) ->RECD£F ; 
CONS (RECDEF, RCOUNT 1 (R. RL, LSSL^CT (R. DF . FN . TL . TL , RSSLCT) , 
RECDEF. FN) ) ; 

END; 


FUNCTION  RCOUNT 1 LR  LRHFl  LRHF2; 

VARS  LRHF3  XU  Xl  X2; 

IF  LRHFl. NULL 
THEN 

(LRHF2.HD) (LENGTH (LR) ) ::NIL;EXIT; 

LR->XU;NIL->X2; 

LOOPIF  NOT (X0. NULL)  THEN 
1->CNT; 

X0.TL->X1; 

LOOPIF  NOT (Xl . NULL ) AND  EQRCCND (XU . HD , Xl . HD, LRHF 1 , LRHFl ) TwEN 
1+CNT->CNT; 


LRtar  3 . ?L->LKH£ 3; 

CLOSE ; 

CONS  ( (LKHi'2.  HD)  ()  ,X2)->X2; 
Xl->XU; 

C LwS  E ; 

X2; 


END; 


FUNCTION  CHANGES  R1  k2  LSLCT1  LSLCT  2; 
JOIix  ( 

DlfRNCE (Rl,R2) , 

DIFAnCE (R2,R1) , 

LSLCT1,  LSLCT  2)  ; 

£ n D ; 
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FUNCTION  DErRECl  RNAME  LRs  ; 

VARS  LRSS  R£  LRHF  X I; 

NIL->LRHF  ; 

2+LENGTri  (LRS  ) ->LRS3 I ZE ; 

RECORDERS  (RNAME, LRS)  ; 

FORALL  111  LRSS IZ E ; 

->X; 

COWS ( X , LRHF ) - > LRHF ; 

CLOSE; 

COWS (RNAME , COWS (LRS , COWS ( LRHF , W I L ) ) ) ; 

EWD ; 


FUNCTION  LOADREL  RNamE; 

VrtRS  LRS  RECDEF  LR  LRSSIZE  I X CriARRPTK  ITEMRPTR  RNM  IPRP; 
POPMESS  ( " In  - ; : (RNAME: : ( . RLT ] ) ) ->CHARRPTR ; 

I WC  HaR  I I'Em  ( CH  A RRPTR ) - > I TR  P ; IT  MR  PI  ( % I Tk  ? % ) - > ITS  M K PTR  ; 

WI L — >LRS  ; 

ITEMRPTR ( ) - >RWM ; 

LOOPIP  (ITEMRPTR () ->X;  WOT (EQU (X , 1 / j ) ) ) THEM 
STIC  KON (X, LRS) ->LRS 
C LO  S E ; 

0EPREC1 (RWM , LRS) ->RECDEF ; 

LENGTH (LRS) -1->LRSSIZE  ; 

NIL->LR  ; 

ITEMRPTR  ()  - >X; 

LOO  PI F NOT  (X=TERM IN ) THEN 
X; 

FORALL  111  LRSSIZE; 

ITEMRPTR  ()  ; 

CLOSE; 

CONS ( (RECDEF. FN. HD) () ,LR)->LR; 

ITEMRFTR  ()  ->X; 

CLOSE  ; 

CONS (RECDEF, LR) ; 

END; 


FUNCTION  ITMRPT  ITRF ; 

VARS  X; 

ITRP  ()  ->X; 

IF  DATAWORD (X ) = "WORD" 
THEN 
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X.WRDCHR; 

ELSE  I 

X; 

CLOSE; 

END; 


FUNCTION  SAVEREL  R FNAME; 

VARS  CUCHAROUT  OUTF  LRS  LRL ; 

POPMESS  (,,OUT”  : : (FNAME:  : [ . RLT  ] ) )->OUTF; 
OUTF ->CUCHAROUT ; 

R. DF. NM. PRSTRING ; 

R. DF. RS->LRS; 

LOO PI F NOT (LRS. NULL)  THEN 
PR (LRS. HD) ; 

LRS . TL->LRS ; 

CLOSE; 

PRSTRING ( ' /@) ; 

R. RL->LRL; 

LOOPIF  NOT (LRL. NULL)  THEN 
PRLIST  (DAT'ALIST  (LRL.  HD)  ) ; 

LRL . TL->LRL ; 

1 . NL ; 

CLOSE; 

POPMESS  ( "CLOSE"  : : (OUTF: :NIL) ) ; 

END; 


FUNCTION  GENREC  RNAME  LRS; 

VARS  RECDEF  LR  LRSSIZE  X Z I; 

0->X; 

DEFRECI (RNAME, LRS) ->RECDEF ; 

LENGTh (LRS) ->LRSSIZ£ ; 

HI L->LR  ; 

•ENTER  DATA  AS  :.«s  . PRSTRING  ; 

LRS . PR ; 

• followed  bt  hub  signals .prstring; 

POPMESS  ( [PROMPT  'DATA:  9 ] ) ->2.; 

1 . NL ; 

LOOPIF  NOT (X ) THEN 

FORhLL  111  LRSSIZE; 

ITEMREADO  ; 

CLOSE ; 

CONS ( (RECDEF. FN. HD) () ,LR)->LR; 
ITEMREADO  ->X; 

CLOSE; 

POPMESS  ( [ PROMPT  Z ] ) ->Z  ; 

CONS (RECDEF, LR) ; 
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END; 


FUNCTION  DF  E; 
R.  HD; 

END; 


FUNCTION  UDF  DFL  R; 
DFL->R. HD; 

END; 


FUNCTION  NM  RECDEF ; 
RECDEF. KD; 

END; 


F UNCTION  IsNM  NMX  RLCDLf  ; 
NMX->R£CDEF. HD; 

EnD  ; 


FUNCTION  KS  RECDEF; 
RECDEF. TL. HD; 

END; 


FUNCTION  URS  R3L  R£CD£F ; 
RSL->RECD£f .TL.HD; 

END; 


FUNCTION  FN  RECDEF; 

RECDEF. TL.TL. HD 

END; 


FUNCTION  UFN  FNL  RECDEF; 

• FNL->RECDEF. TL.TL. HD; 
END; 


FUNCTION  RL  R; 
R.TL; 

END; 


FUNCTION  URL  RLL  R; 
RLL->R.TL; 


END; 


UDF->UPDATER (DF)  ; 
UNM->UPDATER (NM) ; 
URS->UPDATER (RS)  ; 
UFN->UPDATER (FN) ; 
URL->UPDA1ER (RL)  ; 


FUNCTION  PRRLLA'  R; 

VARS  LR; 

R.iRL->LR; 

LuOPIF  NOT  (LR. NULL)  THEN 
PRLIST (DATA LI ST (LR. HD) ) ; 
LR.TL->LR; 

1.  NL? 

CLOSE; 

END; 


FUNCTION  RECSORT  R LSLCT; 

VARS  LERECRD  L; 

IF  LSLCT.  NULL 
THEN 

R. DF . FN . TL . TL->L ; 

ELSE 

LS ELECT (R. DF. FN. TL. TL, LSLCT) ->L ; 
CLOSE; 

LERECORD  (%  L,L  % ) ->LERECRD; 

CONS (R. CF, ALLSORT (R. RL, LERECRD) ) ; 

END; 


FUNCTION  EQRCCND  Rl  R2  LRHFl  LRHF2; 

IF  LRHFl. NULL 
THEN 

TP.UE  ; 

ELSEIF  EOU ( (LRHFl. HD) (Rl) , (LRKF2.HD) (R2) ) 
THEN 

EQRCCND  (Rl,R2,  LRhr'l.TL,  LRMF2.TL)  ; 
ELSE 

FALSE; 

C LOSE ; 


END 
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FUNCTION  GTRECOKD  Rl  K2  L R tip  1 LRHF 2; 

LERLCORD  (R2 , Rl , LRHf 2,  LRhr'l ) AND 
NOT (EQRCCND (Rl , R2, LKttt 1, LKhf 2) ) ; 

LNO; 


f UNCI  low  LtRLCORO  Ri  k2  LRHr'l  LRHF 2 ; 

If  LkHFI.NULL 
THEN 

TRUE  ; 

ELSEIf  (LRHFl.HD) (Rl)* (LRHf2.HU) (R2) 

THEN 

LERLCORD  (Rl , R2 , LRHf  1 . TL , LRlif  2 . TL ) ; 

ELSEIf  IoREAL  ( ( LRiif  1 . HO ) (Rl ) ) OR  IS  INTEGER  ( (LRHf  1 . HU ) (Rl ) ) 
THEN 

(LRHf 1. HO) (Rl ) < (LRHf 2. HD) (R2) ; 

ELSEIf  ECCHAR ( (LRHf 1. HD) (Rl) , (LRHf 2. HD) (R2) ) 

THEN 

LERECORD  (R1,R2,  LRHf  l.  TL,  LRlif  2.  TL)  ; 

ELSE 

LtC rLiR  ( (LRhr'l . HD)  (Rl)  , (LRhr  2.  HD)  (R2)  ) ; 

CLOSE; 

END; 


FUNCTION  RMEMUERS  R LR  LRHf 1 LRHf 2; 

LOOP I f NOT (LR. NULl  OR  GTRECORD (LK . HD , R, LRHF 2 , LkHFI ) ) THEN 
If  EQRCCND (R, LR. Hu, LRHf 1, LRHf 2) 

THEN 

true  ; 

EXIl' ; 

LR. TL->LR; 

CLOSE ; 
f ALSE ; 

END; 


FUNCTION  RME.-1BER  R LR; 

LDOPIF  NOT (LR. NULL)  THEN 

IF  EtfULIST (DATA LI 5T (R ) ,DATALIST (LR. HD) ) 
THEN 

TRUE  ; 

EXIT; 

LR.TL->LR; 

CLOSE; 

FALSE; 


END 
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FUNCTION  GTRECND  R LRHF  PAR; 
IF  ( LRHF. HD) (R)  > PAR 
THEN 

TRUE; 

ELSE 

FALSE; 

CLOSE; 

END; 


FUNCTION  LTRSCND  R LRHF  PAR; 
IF  (LRHF. HD) (R ) < PAR 
THEN 

TRUE ; 

ELSE 

FALSE; 

CLOSE; 

END; 


FUNCTION  LyRECwD  R LRHF  PAR; 

IF  EQU ( (LRHF. HD) (R) , PAR) 
THEN 

TRUE; 

ELSE 

FALSE; 

CLOSE; 

END; 


FUNCTION  EQLRECND  R LRHF  LPAR ; 

LOOPIF  NOT (LPAR. NULL)  THEN 

IF  EQU ( (LRHF. HD) (R) , LPAR. HD) 
THEN 

TRUE  ; 

EXIT; 

LPAR. TL->LFAR ; 

CLOSE; 

FALSE; 

END; 


FUNCTION  TRUECND  K LRhF; 
TRUE  ; 

END; 


J 


COMMENT  RELATIONAL  ALGEBRA  OPEK/VTIoUS: 

LIST  HANDLING  t UnCTIONS  - SURRA  9/7b 
; 


FUNCTION  LSELECT  L LSLCT; 

IF  LSLCT. NULL 
THEN 
NIL; 

ELSE 

CONS  (NSELECT(L,  LSLCT.  HD)  , LSELECT  (L , LSLCT.  TL ) ) 
CLOSE) 

END; 


FUNCTION  LM EMBER  X L; 

IF  L. NULL 
THEN 

FALSE; 

ELSEIF  EQU (X  t L. HD) 

THEN 

TRUE  ; 

ELSE 

LMEMBER (X , L. TL) ; 

CLOSE; 

END; 


FUNCTION  LDIFRNCE  Ll  L2; 

IF  LI. NULL 
THEN 
NIL; 

ELSEIF  LMEMBER (LI. HD, L2) 

THEN 

LD1FRNCE (L1.TL,L2) ; 

ELSE 

CONS ( LI . HD , LOIFRNCC (L1.TL,L2)  ) ; 

CLOSE; 

END; 


FUNCTION  COMPLMNT  L NMAX  N; 

IF  N>NMAX 
THEN 
NIL; 

ELSEIF  LMEMBER  (N  , L) 

THEN 

COMPLMNT ( L , NMAX , N+l ) ; 


CLOSE; 

END; 


FUNCTION  PRLIST  L; 

VARS  LI; 

L->L1; 

LOOFIF  NOT  (LI. NULL)  THEN 
l.SP; 

IF  ISREAL (LI. HD) 

THEN 

FRREAL (LI . HD, 0, 2) ; 
ELSLIF.  ISCOMPND(Ll.HD) 
THEN 

PRSTRI^G (LI. HD) ; 
ELSE 

PR (LI. HD) ; 

CLOSE ; 

LI . TL->L1 ; 

CLOSE; 

END; 


FUNCTION  SQULIST  LI  L2; 

IF  LI. NULL  AND  L2. NULL 
THEN 

TRUE ; 

ELSEIF  LI. NULL  OR  L2. NULL 
THEN 

FALSE; 

ELSEIF  EQU (L1.HD,L2.HD)  AND  EQULI3T (LI. TL, L2. TL) 
THEN 

TRUE ; 

ELSE 

FALSE; 

CLOSE; 

END; 


FUNCTION  STICKON  X L; 
L<> (X: sNIL) ; 

END; 
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FUNCTION  LOR  LI  L2; 

IF  Ll. NULL 
THEN 
NIL; 

ELSE 

CONS (Ll. HC  OR  L2. HD, LOR (Ll. TL, L2. TL) ) ; 
CLOSE; 

END; 


FUNCTION  LAND  Ll  L2; 

IF  Ll. NULL 
THEN 
NIL; 

ELSE 

CONS (Ll. HD  AND  L2. HD , LAND (Ll . TL , L2. TL) 
CLOSE; 

END; 


FUNCTION  LNCT  L; 

IF.  L.NLLL 
THEN 
NIL; 

ELSE 

CONS  (NOT (L.HD) ,LNGT (L.TL) ) ; 
CLOSE; 

END; 


FUNCTION  ELM  NT  w X; 

IF  M»1 
THEN 

X.  HD; 

ELSE 

ELM NT (N~1,X.TL) ; 
CLOSE; 

END; 


FUNCTION  CHNGSLMNT  A N X; 

IF  N«0 
THEN  EXIT; 

IF  N-l 
THEN 

A->X . HD ; 

ELSE 

CHNGSLMNT (A,N-1,X.TL) ; 


CLOSE 


END; 

CHNGELMNT->UFDATER (ELMNT ) ; 


FUNCTION  GEN LSI  0 N; 

IF  N»0 
THEN 
NIL; 

ELSE 

COwS  (U  f GEiMLSTO  (M-l)  ) ; 
CLOSE; 

END; 


FUNCTION  LAND1  L; 

LAND (L , [1  I] ) ; 

END; 


FUNCTION  LORI  L; 

LOR (L , ( 1 1J); 

END; 


FUNCTION  ONLIST  L N; 

IF  L. NULL 
THEN 
NIL; 

ELSEIF  L. HD 
THEN 

CONS  (N  , ONLIST  (L . TL , N+l ) ) ; 
ELSE 

ONLIST (L.TL,N+1)  ; 

CLOSE; 

END; 





_ — ... 


COMMENT  RELA  TIGNAL  ALGE3RA  OPERATIONS: 

3ASIC  GENERAL  FUNCTIONS  - 3ERRA  y/7b 

/ 


FUNCTION  APPENDS  SI  5 2; 

VARS  S 12 ; 

IN ITC (DATA  LENGTH (SI ) +DATALENGTH (S  2 ) )->Sl2 
APPENDS  1 (S1,S12,0) ; 

APPENDS  1 (S  2 , S12 , DATA LENGTH  (SI)  ) ; 

S12; 

END; 

APPENDS->NONOP  <->; 


FUNCTION  APPENDS  1 SI  S2  N; 

VARS  J SSIZE ; 

DATALENGTH (S1)->SSIZ£; 

FORALL  J 1 1 SSIZE; 

SUBSCRC  ( J , SI ) ->SUBSCRC  (J+N,S2)  ; 
CLOSE; 

END ; 


FUNCTION  NS ELECT  L N; 

IF  N-l 
THEN 

L.  HD; 

ELSE 

NS ELECT (L . TL , N-l ) ; 
CLOSE; 

END; 


FUNCTION  EOCHAR  SI  S2; 

VARS  SL  I; 

IF  DATALENGTH (SI) *DATA LENGTH  (S 2 ) 

THEN 

LATALENGTh (S1)->SL; 

FORALL  I 1 1 SL; 

IF  NOT (SUBSCRC (I,S1) -SUBSCRC ( I ,S2) ) 
THEN 

FALSE  ; 

EXIT  ; 

CLOSE; 

1KUL  ; 

E Lb  L 

F A LS  E ; 


EUimC'iIuN  L£.CiiAK  51  52; 

\/m KS  5lL  5 2L  5 IX  5 2a  a'; 

If  51*52 
i’HlN 
TRUE 
EXIT; 

DATA LENGTH (3 1 ) ->31L ;DA  TA LENGTH (32)->S2L; 
1->N  ; 

LO: 

SU3SCRC (N , SI ) ->5 IX ; SUBSCRC (N , S2) ->S2X ; 

If  S1X=3  2X 
THEN 

If  N*5 1L 
THEN 
TRUE 
EXIT; 

IF  N*3  2L 
THEN 

FALSE 

EXIT; 

N + l ->N ; 

GOTO  LO; 

CLOSE; 

S1X<S2X; 

END; 


FUNCTION  EQU  X Y; 

IF  DA.‘"AWORD  (X ) “DATAWORD  (Y ) AND  DAT.AWORC  (X ) * "CSTRIP" 
THEN 

EQCHAR  (X  , Y)  ; 

ELS  E 
X*Y ; 

CLOSE; 

END; 


FUNCTION  WRDCHR  N ; 

VARS  C N I; 

W . DEST'WORD ; 

->N; 

INITC (N) ->C ; 

FORALL  I 1 1 N; 

->SU3SCRC (N+l-I ,C) ; 
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